Question:
Is /usr/lib/libc.so checked last for symbol resolution
(regardless of where it occurs on the link line)?
Background:
I'm working with an executable which is linked with a library
which replicates some entry points of "libc.so". In order to
avoid those symbol collisions, the developers (on Solaris 8)
linked it as follows: cc app.c -lc -lfoo
On Solaris 8, this resolved everything from libc.so except for
the entry points which were *only* in "libfoo". On OpenSolaris,
it also also resolves the symbols common to both libraries
from "libfoo" (rather than from "libc").
As a contrived example, I believe the following resolves "realloc"
from "libmalloc.so" even though "libc" appears earlier in the library
list:
$ echo "int main() { realloc(0,1); }" > x.c
$ cc x.c -lc -lmalloc
"x.c", line 1: warning: implicit function declaration: realloc
$ ldd a.out
libc.so.1 => /lib/libc.so.1
libmalloc.so.1 => /usr/lib/libmalloc.so.1
libm.so.2 => /lib/libm.so.2
/platform/SUNW,Sun-Blade-2500/lib/libc_psr.so.1
$ ( LD_DEBUG=bindings a.out 2>&1 ) | grep realloc
13021: 1: binding file=a.out to file=/usr/lib/libmalloc.so.1: symbol
`realloc'
but on ancient Solaris releases, I believe it resolves from "libc":
Solaris_8 $ ( LD_DEBUG=bindings a.out 2>&1 ) | grep realloc
14366: binding file=/usr/lib/libc.so.1 to file=a.out: symbol `realloc'
14366: binding file=a.out to file=/usr/lib/libc.so.1: symbol `realloc'
I am not advocating for the developer to continue putting "-lc" in the
middle of the link line. Rather, I was hoping to confirm that "libc.so"
is checked last, by design, and that this is not a bug to be reported.
-morgan
