Morgan Herrington wrote:
> Question:
> Is /usr/lib/libc.so checked last for symbol resolution
> (regardless of where it occurs on the link line)?
No. Never has been.
> 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.
The allocation libraries, like libmalloc, libumem, etc. have been tagged
with as object interposers. Thus, when detected as part of process
initialization, they are inspected first for symbols. This is equivalent
to having loaded them with LD_PRELOAD. This tagging came about because of
the introduction of direct binding (in Nevada), but effectively it provides
a more intuitive use of these libraries, as their intent is to interpose
on libc.
% elfdump -d /usr/lib/libumem.so.1
....
[31] FLAGS_1 0x20400 [ OBJECT-INTERPOSE NODIRECT
]
Note, this interposition only occurs if these libraries are loaded as part
of process initialization. If a process was to cause the loading of
libumem as part of a dlopen() or a deferred lazy load, then the
interposition intention is too late, libc is already loaded, and bindings
may have already been establish to its malloc family. ld.so.1's diagnostics
would reveal:
09288: 1: loading after relocation has started: interposition request \
(DF_1_INTERPOSE) ignored: /lib/libumem.so.1
--
Rod.
