GCC brokenness (venting)

Mon Mar 27 09:23:36 UTC 2006

On Mon, 27 Mar 2006, Garrett Kajmowicz wrote:

> 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

--enable-sjlj-exceptions should be necessary for gcc-3.x on uClibc only
but --enable-clocale=gnu means this is on glibc

> 
> Now, as a part of uClibc+ we are using:
> ./gcc -print-file-name=libsupc++.a
$(CC) here, so we get the cross-compiler if set correctly

and arm-softloat-linux-uclibc-gcc print-file=name=libgcc.a returns 
correctly /usr/lib/gcc/arm-softfloat-linux-uclibc-3.4.5/libgcc.a

(above on a gentoo box, having some cross-compilers installed)

> 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

I have checked that one in gcc-svn, and it is needed only on i386 (if the 
system has TLS support). uClibc does not support (yet) TLS (and 
ld-linux.so.2=ld-uClibc.so.0).
The 3 underscore version is used by 32 bit targets, 2 underscores on 64 
bit (the 2 underscore version is provided by all archs)

I wonder generally how this should work correctly in a cross-compiled 
environment, where gcc is built before having libc, so we have no idea if 
TLS will be supported or not.

Chicken and egg problem?

For glibc-2.4 (and uClibc svn) the hardcoded linking to ld-linux.so.2 
should not be necessary, because it is solved internally in libc.so, 
linker script using AS_NEEDED (ld-linux.so.2)
Everything will be linked to ld* if necessary w/o user-interaction, 
requirement being that you built *libc w/ binutils-2.16.1 or newer.

Older glibc (2.3.5) does not have ___tls_get_addr at all.

Peter

> 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
> 

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2