GCC brokenness (venting)

Peter S. Mazinger ps.m at gmx.net
Thu Mar 30 16:12:04 UTC 2006


On Thu, 30 Mar 2006, Rob Landley wrote:

> On Monday 27 March 2006 4:23 am, Peter S. Mazinger wrote:
> > --enable-sjlj-exceptions should be necessary for gcc-3.x on uClibc only
> > but --enable-clocale=gnu means this is on glibc
> 
> And uClibc++ is neither.

the sjlj-exceptions are relevant for the resulting uClibc++ as well, 
because you import libgcc_eh.a and/or libsupc++.a (if enabled)

> 
> > > 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)
> 
> That's the one for the version of gcc installed on the system, but not the one 
> for the version of gcc we built in Garett's home directory (which is the one 
> we were running).  The above command line was testing it from the command 
> line to show the wrong result, not what's in the make file.
> 
> > > 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).
> 
> We were testing uClibc++ on a gcc system.  We can try building a uClibc 
> toolchain and testing with that...

on uClibc TLS does not exist, so libgcc* won't depend on ___tls_get_addr
I have successfully built uClibc++-svn on gcc-4.1.0 (w/ the patches I have 
sent to Garrett to support 4.1, only 4.0 was supported earlier). I am not 
quite sure though about the handling of 4.x due to functions moved around 
between libgcc_s/libgcc/libgcc_eh.

> > 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)
> 
> Even for a static link?

static linking does not/should not require anything from ld-linux.so.2

you could try -Bstatic -lc -Bdynamic if you link libuClibc++.so to 
see (I wouldn't try -lgcc_s, only -lgcc,-lgcc_eh,-lsupc++)

Peter

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

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




More information about the uClibc mailing list