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