GCC brokenness (venting)

Garrett Kajmowicz gkajmowi at tbaytel.net
Mon Mar 27 03:56:51 UTC 2006


GCC is broken.  Not just in general, but in specific.

Rob Landley and I are hanging out in my 1 chair apartment (I love name 
dropping) trying to get uClibc++ to work on gcc 4.1.0 because some people 
seem to think it's better or some such thing.

Anyways, as a test we decided to compile gcc and install it to a non-default 
location /home/garrett/gcc-4.1.0

Build process:
#!/bin/sh

prefix=~/gcc-4.1.0
../gcc-4.1.0/configure --prefix=$prefix --bindir=$prefix/bin 
--includedir=$prefix/include \
--datadir=$prefix/share --mandir=$prefix/man --infodir=$prefix/info \
--libdir=$prefix/lib --with-gxx-include-dir=$prefix/include/g++-v4 \
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec 
--enable-nls \
--without-included-gettext --with-system-zlib --disable-checking 
--disable-werror \
--disable-libunwind-exceptions --disable-multilib --disable-libmudflap 
--disable-libssp \
--disable-libgcj --enable-languages=c,c++ --enable-shared 
--enable-threads=posix \
--enable-__cxa_atexit --enable-clocale=gnu --enable-sjlj-exceptions

Now, as a part of uClibc+ we are using:
./gcc -print-file-name=libsupc++.a
to find and rip chunks out of the binary.  However, we get the system library 
instead of our shiny new one.  Here's a little more information.

./gcc -print-search-dirs
<snip>
libraries: =/home/garrett/gcc-4.1.0/bin/../lib/gcc/i686-pc-linux-gnu/4.1.0/:
/home/garrett/gcc-4.1.0/bin/../lib/gcc/:
/home/garrett//gcc-4.1.0/lib/gcc/i686-pc-linux-gnu/4.1.0/:
/usr/lib/gcc/i686-pc-linux-gnu/4.1.0/:
/home/garrett/gcc-4.1.0/bin/../lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/lib/i686-pc-linux-gnu/4.1.0/:
/home/garrett/gcc-4.1.0/bin/../lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/lib/:
/home/garrett//gcc-4.1.0/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/lib/i686-pc-linux-gnu/4.1.0/:
/home/garrett//gcc-4.1.0/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/lib/:
/home/garrett/gcc-4.1.0/bin/../lib/gcc/i686-pc-linux-gnu/4.1.0/../../../i686-pc-linux-gnu/4.1.0/:
/home/garrett/gcc-4.1.0/bin/../lib/gcc/i686-pc-linux-gnu/4.1.0/../../../:
/home/garrett//gcc-4.1.0/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../i686-pc-linux-gnu/4.1.0/:
/home/garrett//gcc-4.1.0/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../:
/lib/i686-pc-linux-gnu/4.1.0/:
/lib/:
/usr/lib/i686-pc-linux-gnu/4.1.0/:
/usr/lib/

Notice something interesting?

First, it's searching in /usr/lib/gcc/... which is dumb - that's a compiler 
specific directory and we told it to look somewhere else.

Next, it didn't search /home/garrett/gcc-4.1.0/lib for files we need, even 
though we specified that as a directory on the configure line.  It's even 
dumber that the GCC installer put those files there!  It's not searching it's 
own installed files.

To add insult to injury, it's searching /usr/lib/gcc/... at a higher priority 
than most of the subdirectories for the library we specified on the command 
line.  No!  You don't know better.

To work around this, we needed to symlinkthe files down into the tree so gcc 
would find it's own files.

As previously noted, there is an undefined reference to the symbol 
___tls_get_addr which can be resolved by linking against /lib/ld-linux.so.2
This is not something I should have to force to do with any compiler and I've 
been told that it doesn't work with uClibc.  I'm trying to put out another 
release which works with gcc-4.1 and is compatible with uClibc.  I would ask 
the uClibc developer community for suggestions or advice on how to work 
around the gcc ...eccentricities.

I went to the GCC web page to point out non-obvious results and the only way I 
could submit my bug report was to give them my blood type and a complete 
psychological profile.  That just doesn't work for me (if for no other reason 
than that a textarea is too small to hold the profile).  There is no easy way 
to submit the bug.  So it remains unreported.

How should I tell users to do so that they don't need duct tape and a 
sacrificial chicken?


-     Garrett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20060327/a5eec941/attachment-0002.pgp 


More information about the uClibc mailing list