Solaris 9, GCC 4.1.1 and GCC 3.3.5 ... --disable-shared at build time?

[Jeff Blaine]

Let me narrow this down to quick questions then, in case
people don't want to follow the saga below.

1.  Where (in gcc) is the logic for 'link in libgcc_s!'

2.  I rebuilt GCC 3.3.5 (--disable-shared) to reference a
     fresh binutils 2.17 install.  Using that GCC and binutils,
     I still have the weird problem with Python mentioned
     in the quoted text and described in detail here:

 
http://groups.google.com/group/comp.lang.python/browse_thread/thread/9258bc8be76328ad/db117fb149394863?hl=en#db117fb149394863

     What gives? :(

Jeff Blaine wrote:
> [ Sent to gcc list and was told it was the wrong place. ]
> [ Let's try here.                                       ]
> 
> I'm backed into a corner here and really not sure what the
> proper path out is.
> 
> -- Our production GCC is 3.3.5.  It was built with default
>    args.  Previously we ran 2.95.3.  You can perhaps realize
>    my surprise when I found that a lot of apps we had built
>    with this GCC 3.3.5 had libgcc_s.so linked dynamically
>    to them.  You can perhaps also realize my surprise when
>    I came to this conclusion after a lot of stuff broke when
>    I expired our GCC 3.3.5 install in favor of 4.1.1.
> 
> -- But okay.  This process at least made one thing clear.
>    We need to offer our users multiple GCC versions.  Some
>    want 3.3.x, some want to test 4.1.1's pedantic nature,
>    etc.
> 
> -- So I says to my self, "Self, when you go to build the
>    new multiple GCCs in the new production language area,
>    build them with --disable-shared so N tens of apps are
>    not depending on your GCC staying put in order for them
>    to function (!??).
> 
>    I build GCC 3.3.5 and 4.1.1, both with --disable-shared.
>    I do this for Solaris 9, 10, Linux 2.4 for i686, and
>    Linux 2.4 for AMD64.  Yes, a hoot.  Weeks pass during
>    this time and the leaves begin to fall.
> 
>    Oh, and the Solaris ones were built to reference the
>    Sun 'as' and 'ld' (/usr/ccs/bin).
> 
> -- In order to redo all of the "broken because they're linked
>    to libgcc_s.so" apps, I set my PATH to use the new
>    compilers (the ones that were built with --disable-shared).
>    I find that my life is hell, as just about half of every-
>    thing I try to build under Solaris 9 does not build.
> 
>    I get text relocation errors from our built libz.a,
>    I fail to build subversion for mysterious reasons/errors,
>    I get Python 2.4.x to build fine without libgcc_s.so
>    linked to it, then I drop a Modules/Setup.local in place,
>    make again to build the modules, and everything goes to
>    hell with a new ./python that is now magically linked
>    to libgcc_s.so (the old one we have to keep around until
>    our apps are rebuilt).
> 
> It would seem that GCC 3.3.5 + Sun as + Sun ld do not play
> nice at all with libraries previously created with GNU
> binutils.
> 
> So... could someone elaborate on what it is I am doing that
> is so wrong?  What is the successful recipe for using GCC
> 3.3.5 + 4.1.1 and/or binutils under Solaris?
> 
> 
> 
>