dlsym() may return an undefined symbol

Cédric Hombourger chombourger at nexwave-solutions.com
Mon Jan 15 18:55:08 UTC 2007


 
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