This is the mail archive of the
mailing list for the GCC project.
Re: GCC 3.2 Success (sort of) on Solaris 2.5.1
- From: Janis Johnson <janis187 at us dot ibm dot com>
- To: Jesus Cea Avion <jcea at argo dot es>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 28 Aug 2002 09:45:32 -0700
- Subject: Re: GCC 3.2 Success (sort of) on Solaris 2.5.1
- References: <3D6CB0DE.F769AEEF@argo.es>
On Wed, Aug 28, 2002 at 01:15:42PM +0200, Jesus Cea Avion wrote:
> Please, update http://gcc.gnu.org/gcc-3.2/buildstat.html
Thanks for this information. Your message is now linked from the GCC 3.2
build status list, but as unsuccessful. See below for more information
about why I did it that way.
> If you answer this email, please, send me a copy since I can't cope with
> the volume of this mailing list.
> This is a horror history. Please, read carefully. I've spend three weeks
> with this. I will make a long story short:
> Initial State: gcc 2.95.3, binutils 2.11.2.
> a) I upgrade binutils to last version, 2.13. *Caution here. See later.*
> b) GCC 3.2 configuration:
> # gcc -v
> Reading specs from
> Configured with: ../gcc-3.2/configure --with-gnu-as
> --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld
> --disable-nls --enable-languages=c,c++ --disable-libgcj --disable-shared
> Thread model: posix
> gcc version 3.2
> c) "make bootstrap".
> d) "compare between "stage2" and "stage3" fails miserably. The "*.o" are
> differents but an "objdump -D" shows that "stage2" and "stage3" object
> files are "equivalent". That is, the "*.o" files are not equal, but
> disassembly are the very same.
A bootstrap is only successful if the compare of stage2 and stage3
succeeds. A compare failure indicates a serious problem of some kind;
I don't know what would cause the disassembly to be the same but the
compares to fail, but I would expect the GNU assembler to generate
the same .o files for the same compiler output.
> e) I patch "gcc/Makefile" to skip comparison between "stage2" and
> "stage3" binaries, since they are not equal but seems to be
> "equivalent". I don't know/understand the reason.
> f) "make install"
> And now all is running fine... until I try to compile a shared lib. The
> compilation and linking goes fine, but when anybody tries to use the
> shared lib, the program core dumps.
> I finally determine that GNU binutils "ld" is the problem. I was using
> binutils 2.13. I compile binutils 2.12.1, install *ONLY* the "ld"
> component (I keep the other 2.13 utils and libraries) and every goes
> fine now.
See the message at http://gcc.gnu.org/ml/gcc/2002-08/msg01834.html from
Vee Voon Yee, who reports the same problem with ld 2.13 on Solaris 2.6.
I recommend starting over, this time using binutils 2.12.1, unless
someone who knows more about this problem responds with better advice.