This is the mail archive of the 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]

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

On Wed, Aug 28, 2002 at 01:15:42PM +0200, Jesus Cea Avion wrote:
> Please, update

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 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]