[uClibc] dlsym finds symbols in libraries other than the ones pecified

Joakim Tjernlund joakim.tjernlund at lumentis.se
Tue Aug 10 13:36:07 UTC 2004

> Hello Jocke,
> Thanks a lot! This is what I need.
> > Can you test and comment?
> I tested it (on arm), added some printf's to follow what libs are searched
> and it certainly works for me.

Good, I checked it into CVS already :)

> > Note:
> >   RTLD_LOCAL hanling is still broken. Everything is RTLD_GLOBAL.
> >From user point of view, the behavior now is as if every lib is loaded with
> RTLD_LOCAL (or just without RTLD_GLOBAL). I think this is the more typical
> use of dlopen/dlsym.

from SUSv3:
"Any object loaded by dlopen() that requires relocations against global symbols can reference the symbols in the original process
image file, any objects loaded at program start-up, from the object itself as well as any other object included in the same dlopen()
invocation, and any objects that were loaded in any dlopen() invocation and which specified the RTLD_GLOBAL flag. To determine the
scope of visibility for the symbols loaded with a dlopen() invocation, the mode parameter should be a bitwise-inclusive OR with one
of the following values:

The object's symbols shall be made available for the relocation processing of any other object. In addition, symbol lookup using
dlopen(0, mode) and an associated dlsym() allows objects loaded with this mode to be searched.

The object's symbols shall not be made available for the relocation processing of any other object.

To me this means:
RTLD_GLOBAL/RTLD_LOCAL only affects relocations. If RTLD_GLOBAL is specified, other libs may relocate symbols
against the dlopened library(and its NEEDED libs). RTLD_LOCAL does not allow this.

dlsym() is not affected by these flags unless dlsym operates on a handle which has been obtained by dlopen(0, ..).

Correct or not?

> Peter.

More information about the uClibc mailing list