Jeff Blaine wrote:
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? :(
BTW, Subversion too:
subversion-1.2.0:cairo> gcc --version
gcc (GCC) 3.3.5
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
subversion-1.2.0:cairo> ld --version
GNU ld version 2.17
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of the GNU General Public License. This program has absolutely no warranty.
subversion-1.2.0:cairo> gcc -print-libgcc-file-name
/afs/rcf.mitre.org/lang/gcc/@sys/3.3.5/bin/../lib/gcc-lib/sparc-sun-solaris2.9/3.3.5/libgcc.a
subversion-1.2.0:cairo> make clean
...
subversion-1.2.0:cairo> make
...
subversion-1.2.0:cairo> ldd subversion/clients/cmdline/.libs/svn | grep
gcc_s
libgcc_s.so.1 => /usr/rcf/lib/libgcc_s.so.1
subversion-1.2.0:cairo> STOP DOING THAT
-/usr/local/bin/bash: STOP: command not found
:(
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?
