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