GCC brokenness (venting)

[Steven J. Hill]

Garrett Kajmowicz wrote:
> GCC is broken.  Not just in general, but in specific.
>
Or your brain is. Let's find out.

> 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.
>
If you want to use NPTL in uClibc (or glibc for that matter), you will have
no choice but to use 4.1.0 for MIPS, ARM, SH, and possibly PPC. No backports
will be done to earlier compiler revisions. Sorry. Actually, x86 and PPC
NPTL are available with GCC-3.4 series compilers. I like trivia, anyway....

> 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
> 
Wow, that's a lot of crap. Looks like you were playing with PPC stuff too. Did 
you look to see how crosstools is doing things to see if you are missing
something? I have been building x86 and MIPS NPTL glibc toolchains for months
now with C/C++ support using GCC-4.1.0 and have had no issues with search paths.
Also, please tell me you are not building within the GCC source tree itself.
It is hard to tell from your shell script, but it looks like you may be doing
that. Don't. Also, is there some reason you are not using buildroot or are you
wanting to build glibc stuff to compare against in order to get uClibc working?

> 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.
>
The reason __tls_get_addr exists is two-fold. First, your assembler supports
TLS data and thus the check in 'gcc/configure' for the data type '__thread'
passes which allows the compiler to emit usage of __tls_get_addr. Secondly,
due to the problems you are having with search paths and such, the libraries
that are being picked up by your compiler have TLS data in them and thus that
symbol is being brought into your libraries and binaries. It should be noted
that __tls_get_addr is ALWAYS defined in the C library implementation, whether
glibc, uClibc or stupidlibc. It does not exist in binutils or GCC. You probably
already figured that out.

To re-iterate, try looking at the crosstools stuff. I submitted patches months
ago based off of someone's NPTL work on earlier GCC versions in order to get
GCC-4.1.0 working properly. It took me probably close to 15 test builds to get
the steps right.

-Steve