[uClibc]Possible subtle problem with dynamic linked applications

[Erik Andersen]

On Tue Dec 18, 2001 at 10:10:28AM +0100, Gianci wrote:
> Hello all,
> 
> I had some trouble for a while because all my uClibc-compiled
> applications suddenly and unexpectedly started to segfault on
> my workstation, but not on the target system.
> 
> After some investigation I finally found the reason. I created a static
> link /lib/libc.so.0 to the standard shared C library (it was needed by
> another application). 
> 
> It is this link that causes all uClibc dynamic linked applications to
> crash on a Linux system with both uClibc and the standard glibc library.
> 
> If you strace a uClibc application in a clean system you will get
> something like this:
>  
> embedded at linux:/tmp > strace -e trace=open ./hello
> open("//usr/lib/libc.so.0", O_RDONLY)   = -1 ENOENT (No such file or directory)
> open("//lib/libc.so.0", O_RDONLY)       = -1 ENOENT (No such file or directory)
> open("/usr/i386-linux-uclibc/lib/libc.so.0", O_RDONLY) = 3
> Hello
> embedded at linux:/tmp > 
> 
> If /lib/libc.so.0 or /usr/lib/libc.so.0 is a link to /lib/libc.so.6 this
> is what you will get:

If libc.so.0 is a link to /lib/libc.so.6, then uClibc has been
installed incorrectly.  libc.so.6 is GNU libc.  If your uClibc
app tries to run using GNU libc (which is apparently how your
system is setup), segfaults are fully expected.  i.e. Don't do
that.  Leave libc.so.0 pointing to uClibc and your uClibc apps
will work much better.

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--