[TRE-general] Weird bug
Ville Laurikari
ville at laurikari.net
Tue May 16 22:23:45 EEST 2006
On Mon, May 15, 2006 at 09:06:19PM +1000, skaller wrote:
> Within one module yes. It's possible to link both with shared libs:
> X links to tre and Y to gnu, A links to X and Y and passes data
> between them without needing to link to either tre or gnu.
I tried this. I made two dynamically linked libraries, X and Y. X
compiles a regex object using regcomp() and returns it. Y runs a
regexec() for a given compiled regex. A gives a regex object made
with X to Y. X is explicitly linked with libtre.
Both the regcomp() and regexec() calls go to TRE if A is linked with
libtre. If A is not linked with libtre, both calls go to libc. So I
was unable to get an inconsistent link like this.
This seems to come down to the link order and the fact that symbols
are bound by the dynamic loader for the entire program instead of
separately for each loaded library.
A not linked with libtre (but X is):
ldd a:
./x.so => ./x.so (0x40019000)
./y.so => ./y.so (0x4001b000)
libc.so.6 => /lib/libc.so.6 (0x4002c000)
libtre.so.4 => /p/lib/libtre.so.4 (0x4013f000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
A linked with libtre (and so is X):
ldd a:
./x.so => ./x.so (0x40019000)
./y.so => ./y.so (0x4001b000)
libtre.so.4 => /p/lib/libtre.so.4 (0x4001e000)
libc.so.6 => /lib/libc.so.6 (0x4003b000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
In both cases,
ldd x.so:
libtre.so.4 => /p/lib/libtre.so.4 (0x40002000)
libc.so.6 => /lib/libc.so.6 (0x4001f000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
ldd y.so
libc.so.6 => /lib/libc.so.6 (0x40010000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
Note that this was on Linux and glibc, think may work differently on
other platforms...
I am aware that there are linker flags which can probably be used to
change how symbols are bound, but at least with default settings this
is how things go.
--
http://www.iki.fi/vl/
More information about the TRE-general
mailing list