[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