Re: GCC 3.2 Success (sort of) on Solaris 2.5.1

[Janis Johnson <janis187 at us dot ibm dot com>]

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
> /usr/local/lib/gcc-lib/sparc-sun-solaris2.5.1/3.2/specs
> 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.

Janis