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]

Re: Grief with Dejagnu; Testing gcc 2.95.3.test4 on SCO OS5.0.4


David Gressett wrote:
> At 08:33 AM 2/26/2001 -0600, you wrote:
> > > make[5]: Entering directory `/u7/objdir2/gcc'
> > > ./xgcc -B/usr/local/i386-pc-sco3.2v5.0.4/bin/ -B./
> > > -I/usr/local/i386-pc-sco3.2v5.0.4/include -O2   -DIN_GCC     -O2 -g -O2
> > > -I./include   -g1  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED    -g -O2 -I.
> > > -I../../gcc-2.95.3.test4/gcc -I../../gcc-2.95.3.test4/gcc/config
> > > -I../../gcc-2.95.3.test4/gcc/../include \
> > >    -c -fexceptions ../../gcc-2.95.3.test4/gcc/cp/exception.cc
> > > xgcc: Internal compiler error: program as got fatal signal 11
> >
> >While RAM bugs might be fun to chase, my money is that this is an
> >assembler bug.  If you can't upgrade the whole OS, at least pick up
> >tls706 from ftp://ftp.sco.com/TLS/ to get a fixed assembler.
> 
> bingo. problem solved.

Since I was the one that put that TLS together, my bet was safe. :-)

Could you submit a patch to specific.html to document this?  Would you
have known to look there anyway?

> >This is a hint that someone is using "-belf" to GCC ("look in a
> >directory named elf".  This would be wrong; -belf is a valid flag to
> 
> I ran the build from my Kermit-95 terminal emulator and saved all the 
> screen output to a session log. I found no trace of -melf, -belf, or any 
> other kind of elf being applied to gcc.

OK, that's interesting.  It still feels like you have some other
mishandling of -b that's being plastered over with your symlink becuase
what you describe shouldn't be necessary and, in fact, hasn't reported
by others.  Can you show us the precise command being issued and the
failure generated?  Cut/paste from your kermit logs is fine. 'script'
can also be your friend for this sort of thing.   Do you have something
in your environment that might be tripping the build?

> the problem in ltconfig is that it assumes that SCO OSR5 will always
> use the SCO cc. The tcl and expect in the last dejagnu snapshot have
> the same problem in config.in, which does get used. I haven't looked

Sigh.  More config machinery that needs fixed...Remember the days when
GCC was self-contained you could fix problems by fixing the tree and not
becoming an expert in all these other tools and languages?

RJL


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