Re: Re: libgcc --disable-shared test case

[Rich Felker <dalias@aerifal.cx>]

On Sat, Jan 11, 2014 at 04:04:25PM -0600, Rob Landley wrote:
> >If you could share the two versions of libfoo.so, a.out, and maybe
> >even libgcc.a, I can probably figure out what's going on.
> 
> Tarball of the newly built stuff attached, the other stuff should be
> at http://landley.net/simple-root-filesystem-i686.tar.bz2 (which
> isn't the release version because I made sure this one _wasn't_
> built from a stage 2 cross compiler. This is from an aboriginal
> build that didn't do a stage 2 cross compiler, but built everything
> with the "simple" cross compiler.)

OK, here's my analysis. a.out does not contain __divdi3, which it
should, but instead contains an undefined reference to it. libfoo1.so
contains a definition for __divdi3, and libfoo2.so does not. So far,
this is all exactly how I expected the linking against a broken
libgcc.a to manifest.

So, why does it "work"? Because your uclibc was also built against
this broken libgcc.a, and thus exports __divdi3 and whatever subset of
the libgcc symbols *happened* to get used by code in libc. If you
replace it with a properly built uclibc libc.so.0 (i.e. one built with
a gcc toolchain that was not using --disable-shared), your a.out will
definitely stop working. If this weren't troubling enough, it could in
principle just stop working as a result of internal changes to uclibc.
(This is unlikely with __divdi3, whose use is extremely common, but it
could easily happen with the other weird libgcc functions used for
dispatching switch statements on long long, floating point to long
long conversions, etc.)

If you want to see the issue manifest without replacing uclibc, the
easiest way would be to check *which* libgcc symbols got pulled into
libc.so.0, then modify the test code for libfoo.so to use a feature
that will pull in one of the libgcc symbols not in libc.

Rich