_dl_app_init_array and _dl_app_fini_array problems

Carmelo Amoroso carmelo73 at gmail.com
Fri Oct 6 07:47:46 UTC 2006


Ricard Wanderlof wrote:
> 
> On Thu, 5 Oct 2006, Kevin Day wrote:
> 
>>> For some reason, the ld-uClibc.so.0 (aka ld-uClibc-0.9.29.so) is not
>>> being created as a shared  object, so attempts to link against it do
>>> not seem to work properly.
> 
> I may be totally out of line here, but isn't ld.so (or ld-uClibc.so.0) 
> in actual fact _not_ a library, but rather the dynamic linker/loader 
> that in turn interprets an executable file, loading further shared 
> libraries as needed?
> 
> This, ld.so is the 'interpreter' for an ordinary executable, similar to 
> the way /bin/sh is the 'interpreter' for a shell script starting with
> #!/bin/sh .
> 
This is true, but from an ELF point of view, the ELF type of the ld.o is 
DYN, so if ldd is failing while reading Kevin's ld.so, it means that
probably his loader is broken.

> 'Linking against' ld.so means inserting a reference to ld.so in the 
> executable so that ld.so is run, loading the executable, and then 
> continuing from there.
>
libc.so.0 depends on ld.so itself for some symbols (_dl_app_init_array 
for example), and it will added to the modules chain by the ld.so itself
for symbol loookup.

The problem is: why Kevin's loader is not well-formed?

Carmelo

> See also man ld.so .
> 
> Sorry, this isn't directly uClibc related, but seems to be related to 
> the actual topic discussed.
> 
> /Ricard
> -- 
> Ricard Wolf Wanderlöf                           ricardw(at)axis.com
> Axis Communications AB, Lund, Sweden            www.axis.com
> Phone +46 46 272 2016                           Fax +46 46 13 61 30
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> uClibc mailing list
> uClibc at uclibc.org
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc




More information about the uClibc mailing list