[uClibc] arm toolchain/static binaries

Rob Landley rob at landley.net
Sat Jun 19 09:51:37 UTC 2004


On Wednesday 16 June 2004 10:04, David Muse wrote:
> Hello all,
>
> I've been using an arm-uclibc toolchain based on uclibc-0.9.21 for a while
> now and I recently tried to upgrade to a toolchain based on the current cvs
> snapshot.  I have been able to compile a complete toolchain and it can
> build most of my code, but every now and then, it generates a static
> binary.  If I rebuild the same code base again, the same binaries get
> linked statically, so it's not exactly random, but I can't figure out why
> it's linking them statically.  I'm not passing any flags that would cause
> static linking, dynamic versions of each of the libraries that need to be
> linked in are available, and the 0.9.21 toolchain builds dynamically linked
> binaries.  It's kind of a subtle bug, I didn't notice it for a while until
> one day I just noticed that the size of the jffs2 filesystem image that my
> build process generates was larger than I remember.
>
> Has anyone else seen this?

A couple of possibilities.

1) The .so files are in your libpath, but the .a files aren't.  For some 
reason, gcc or binutils or whatever creates statically linked programs if it 
finds the wrong kind of shared library.  (The relocation information is 
missing from one of then, or something like that.  Beats me.)

2) Your binutils lib path has the same directory in the path twice, so it's 
finding things twice.  This _also_ causes it to create huge bloated 
(effectively staticly linked) executables, but with the added benefit that it 
still insists on loading the shared libraries as well at run time, and 
refuses to run without them.

I encountered the second problem due to a filesystem simplification I do: the 
split between the /usr directory and / is a historical relic dating back to 
Ken and Dennis running out of space on their 2.5 megabyte RK05 disk pack in 
1972, and allowing the OS to leak into the second disk where the user 
directories were stored.  Eventually they created /home and movedthe user 
directories there, but the /bin->/usr/bin and so on duplication has been with 
us ever since, for no good reason.

So I cleaned it up, making /bin a symlink to /usr/bin, /sbin a symlink to 
/usr/sbin, and /lib a symlink to /usr/lib.  And life was mostly good except 
for /lib and /usr/lib both being in the path, causing binutils to create huge 
bloated executables.  Sigh...

You can tell the difference by doing ldd on the files.  If they still want to 
link to the shared libraries they should, it's the second problem.  If they 
don't, it could be the first.

The fix for the second problem (which quite possibly nobody but me has ever 
run across) is, of course...  (Let's see, where's my build script for 
this...)

In binutils:
sed -i -e 's@^NATIVE_LIB_DIRS.*@NATIVE_LIB_DIRS=/usr/lib@' 
binutils-2.14/ld/configure.tgt

And in gcc:

cat gcc/collect2.c | grep -v '"\/usr\/lib"' | grep -v '"\/usr\/local\/lib"' > 
gcc/collect2.bak
mv gcc/collect2.bak gcc/collect2.c

I think that's it.  They just make the symlinks and build.  Oh, and make sure 
that none of the installs try to cp -f stuff to /lib but instead copies it to 
/lib/ because otherwise it'll overwrite the symlink.  (Yes, the culprit here 
was the make install of uclibc.  Most of the other ones use "install" rather 
than cp -f, and that seems to get it right...)

Rob

(P.S.  Someday, I will figure out the difference between "ld" in binutils and 
"collect2" in gcc.  And then I'll probably want to hit somebody, but that's 
pretty common when dealing with FSF code.  I try to avoid it as much as 
possible, really...)

-- 
www.linucon.org: Linux Expo and Science Fiction Convention
October 8-10, 2004 in Austin Texas.  (I'm the con chair.)




More information about the uClibc mailing list