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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?







[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux