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

Jeff Blaine jblaine@mitre.org
Tue Oct 31 00:14:00 GMT 2006


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?



More information about the Gcc mailing list