[uClibc] ldso bug in uclibc?

Joakim Tjernlund joakim.tjernlund at lumentis.se
Mon Nov 8 13:48:54 UTC 2004


> 
> > > Correct. m_handle = dlopen(dllName, RTLD_LAZY);
> > >
> > > Is this not just a matter of having the "struct elf_resolve *tpnt"
> > > structures store the RTLD_GLOBAL/RTLD_LOCAL state (if they don't
> > > already). _dl_find_hash then doesn't search a non-local and non-global
> > > symbol table if it doesn't have RTLD_GLOBAL set. This assumes our
> > > "implementation defined behaviour" for when neither is set is to pretend
> > > RTLD_LOCAL was passed.
> >
> > No, not that easy. You must also consider the NEEDED libs when dlopening a
> > lib. All NEEDED libs(that aren't already opened) will belong to the same
> > RTLD_LOCAL group. Any libs relocation in the same RTLD_LOCAL group can
> > relocate against any other lib in the group.
> >
> > You search all libs in load order, starting with the exe.
> > To search a lib for symbols that lib must either have
> > RTLD_GLOBAL set or that lib must belong to the same RTLD_LOCAL group.
> >
> > This is how I read the spec, I might be wrong though.
> 
> Yeah - this is how I read it. But I must be missing something - what do you 
> mean by an RTLD_LOCAL group? I don't see anything like that on that opengroup 
> page. My reading is that syms in a library are either all local or all 
> global... I don't see any way of grouping libraries together.

Usally a lib also depend on other libs, like libc, libm. These dependencies are
recorded in the DT_NEEDED entries in the dynamic section. The dlopened lib AND
the libs it depends on are in the same RTLD_LOCAL group. One or more
libs in the dependency chain may already be opened with RTLD_GLOBAL, such
a lib will stay as RTLD_GLOBAL.

 Jocke



More information about the uClibc mailing list