GCC brokenness (venting)

[Rob Landley]

On Sunday 26 March 2006 11:44 pm, Steven J. Hill wrote:
> 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....

Actually, Garrett was just trying to get uClibc++ to work with gcc 4.1.0.  
Because gcc isn't well-designed, the C++ library contains some things that 
are really gcc internals (the stack unwinding code and compiler interfaces 
for type identification you just can't recreate without the gcc source code; 
they're version specific and configuration specific), and _doesn't_ contain 
some things you'd think it should (the base class for Exceptions is 
hard-wired into the compiler; replace the one in the libstdc++ with a smaller 
one and it complains about a size mismatch).  That's why you have to build 
libstdc++ first in order to build uClibc++ from it: he has to cherry pick 
symbols out of the other library which can't be recreated without rebuilding 
gcc.

He uses gentoo, so it was relatively easy to rebuild gcc from source, and we 
were trying to figure out if using things like sjlj stack unwinding might 
actually be more portable between versions.  (And might also be something we 
could recreate in uClibc++ so that if you configure gcc _this_ way, you don't 
have to copy those symbols from libstdc++ but uClibc++ could actually build 
something workable itself.)

We didn't get that far.  It's a mess...

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

That's the gentoo config, plus --enable-sjlj-exceptions, minus the darn 
fortran compiler it was building (for no readily apparent reason).  We also 
fed it a different destination path (in his home directory).

> Looks like you were playing with PPC stuff too. 

Not that I know of.  Who knows what gentoo was doing?

> Did you look to see how crosstools is doing things to see if you are
> missing something?

We looked to see what gentoo was doing.  On x86.  The above config did in fact 
produce a working compiler.  Gentoo built itself with it.

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

We weren't, although I don't see what that's supposed to break.

> It is hard to tell from your shell script, but it looks 
> like you may be doing that. Don't.

Why not?  (I repeat that we didn't, but projects are supposed to be able to 
build within their own source trees.  I take it this is yet another thing 
broken or unreliable about gcc?  Or is it merely an aesthetic issue?)

> Also, is there some reason you are not 
> using buildroot

Becuase buildroot is a complicated series of nested make files and we were 
just trying to get a compiler we run test builds with, not a full system?  
Plus we were trying to do so for x86, and we weren't trying to link it 
against uClibc?

> or are you wanting to build glibc stuff to compare against 
> in order to get uClibc working?

uClibc++.

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

Strange that we couldn't find it in glibc, then.  (We didn't rebuild glibc.)  
The _only_ library we could find it in was ld-linux.so.2.

> It does not exist in binutils or GCC. You probably already 
> figured that out.

Maybe this is a gentoo thing.  I don't know.  (I use ubuntu.)

> To re-iterate, try looking at the crosstools stuff.

For x86.

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

Ok...

> -Steve

Rob
-- 
Never bet against the cheap plastic solution.