This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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 Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]