dlsym() may return an undefined symbol
Joakim Tjernlund
joakim.tjernlund at transmode.se
Mon Jan 15 21:25:02 UTC 2007
hmm, I realize was a bit unclear. I get the NULL ptr
behaviour without the patch below. After looking a bit harder
at this problem I think the current behaviour in SVN is correct.
Need some more time on that new patch for 2).
Jocke
> -----Original Message-----
> From: Cédric Hombourger [mailto:chombourger at nexwave-solutions.com]
> Sent: den 15 januari 2007 19:55
> To: Joakim Tjernlund; uclibc at uclibc.org
> Subject: RE: dlsym() may return an undefined symbol
>
>
> Hi there,
>
> Many thanks for your support
>
> It seems that 0.9.29 (svn) and 0.9.28 indeed returns a NULL
> pointer and this behaviour (while different from glibc) is
> perfectly fine with our application.
>
> I am willing to test your fix for (2) if that helps.
>
> Cedric
>
> -----Original Message-----
> From: Joakim Tjernlund [mailto:joakim.tjernlund at transmode.se]
> Sent: Sunday, January 14, 2007 10:03 PM
> To: Cédric Hombourger; uclibc at uclibc.org
> Subject: RE: dlsym() may return an undefined symbol
>
>
>
> > -----Original Message-----
> > From: uclibc-bounces at uclibc.org
> > [mailto:uclibc-bounces at uclibc.org] On Behalf Of Joakim Tjernlund
> > Sent: den 12 januari 2007 16:26
> > To: Cédric Hombourger; uclibc at uclibc.org
> > Subject: RE: dlsym() may return an undefined symbol
> >
> > Hi Cedric
> >
> > Had a quick look at this and it migth be that the problem is easily
> > fixed by this:
> > Index: ldso/libdl/libdl.c
> > ===================================================================
> > --- ldso/libdl/libdl.c (revision 17166)
> > +++ ldso/libdl/libdl.c (working copy)
> > @@ -442,7 +442,7 @@
> > }
> > }
> >
> > - ret = _dl_find_hash((char*)name, handle, NULL, 0);
> > + ret = _dl_find_hash((char*)name, handle, NULL,
> > ELF_RTYPE_CLASS_PLT);
> >
> > /*
> > * Nothing found.
> >
> > However I am far from sure about this. Especially on other
> > arch's than MIPS since
> > on MIPS type_class is always equal to ELF_RTYPE_CLASS_PLT for
> > all other lookups
> >
> > Would be great if you could test this on MIPS and x86.
> >
> > Jocke
> >
> > > -----Original Message-----
> > > From: Cédric Hombourger
> [mailto:chombourger at nexwave-solutions.com]
> > > Sent: 12 January 2007 14:10
> > > To: Joakim Tjernlund; uclibc at uclibc.org
> > > Subject: RE: dlsym() may return an undefined symbol
> > >
> > >
> > > Hello Jocke, thanks for your quick response and apologies for
> > > the HTML post that I did. Yes I am more than aware that
> > > 0.9.27 is rather old but we unfortunately have to integrate
> > > our S/W component loader and runtime into a Linux-based
> > > solution provided by a thirdparty (who delivers to us
> > > binaries of the linux kernel, uclibc 0.9.27, and of their
> > > software stack). We will push for an upgrade to 0.9.28...
> > >
> > > I have reproduced this behaviour with a SVN checkout of
> > > uclibc from yesterday. Unfortunately, if I turn on traces
> > > then I get a segv (that I will investigate). You will find
> > > attached the test program that I used on mipsel-linux-uclibc
> > > and below are the traces that I got with LD_DEBUG=all
> > > defined. Note that the test program works just fine on
> > > mipsel/glibc 2.3.2 (dlsym() returns the same pointer for both
> > > calls) while on uclibc, the pointer returned by the second
> > > dlsym() is a pointer to .MIPS.stubs resolving a completely
> > > different symbol.
> > >
> > > Again thank you for your response, and please let me know if
> > > there is something else you need.
>
> Hi again
>
> When testing this on PPC I get a NULL ptr for malloc2 and
> having looked more at this issue I see that the current libdl impl.
> don't search libs that is already loaded(libc is this case).
> So I think there is two problems here:
> 1) You should get a NULL ptr back with current SVN impl. and .28
> 2) dlopen needs to be fixed to actually add the dependent libs to the
> search list even if these libs are already loaded.
>
> MIPS is a very odd animal when it comes to dynamic linking so you
> you may have a MIPS specific bug for 1)
>
> for 2) I got something that should fix the problem for
> SVN and probably .28 as it is very similar to SVN. Got to clean it
> up a little first.
>
> Jocke
>
>
>
>
More information about the uClibc
mailing list