[uClibc]Shared libm issue on SH

M. R. Brown mrbrown at 0xd6.org
Wed Jan 9 12:51:46 UTC 2002


* Erik Andersen <andersen at codepoet.org> on Wed, Jan 09, 2002:

> 
> > # ldd /usr/local/bin/madplay
> > 	libm.so.0 => /lib/libc.so.0
> > 	libc.so.0 => /lib/libc.so.0
> > 	/lib/ld-linux.so.2 => /lib/ld-linux.so.2
> 
> That is pretty odd.   Could be a bug in the uClibc ldd
> implementation though.  Lets check using the trick above.  (BTW,
> madplay is a fine choice for an mp3 player, and I've run it on
> x86 and ARM using uClibc).
> 

Yep:

# LD_TRACE_LOADED_OBJECTS=1 /usr/local/bin/madplay
        libm.so.0 => /lib/libm.so.0 (0x2957c000)
        libc.so.0 => /lib/libc.so.0 (0x29592000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x29556000)

(yes, madplay is nice, I have to get around to implementing SH-specific
math routines, eventually).

> 
> Do you have DOLFS enabled in uClibc?  I see the glibc lib loader
> is using the large file versions of things, which could be a
> problem if you have those disabled....
> 

Heh, the comments in the default Config.sh suggested that DOLFS wasn't
needed/implemented (you might want to update those).  But I recompiled with
DOLFS=true, and unfortunately there's no change in behaviour.

Could this be isolated to libm.so?  I can have other apps linked against
stuff like libncurses that run fine.  Initially I was worried about the
undefined reference to main in the original build step, so I recompiled
uClibc for i386 to see if it was a SH-only thing.  It was.  Are you certain
there isn't a missing init sequence somewhere in libc/libm (ignorance of
uClibc source shines through ;))?

M. R.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20020109/7e81156b/attachment.pgp 


More information about the uClibc mailing list