RE: GCC 2.95.2 crosscompile broke under latest Cygwin

["Alex Holland" <alexh at stellarwinds dot com>]

Thank you for this informative hypothesis. However, I renamed my current
cygwin installation and did a completely new install of the latest cygwin
and native GCC tools with none of my old cygwin tree in my $PATH.

Then I ran the following script for crosstool,

#!/bin/sh
set -ex
TARBALLS_DIR=$HOME/downloads
RESULT_TOP=/opt/crosstool
export TARBALLS_DIR RESULT_TOP
GCC_LANGUAGES="c,c++"
export GCC_LANGUAGES

# Really, you should do the mkdir before running this,
# and chown /opt/crosstool to yourself so you don't need to run as root.
mkdir -p $RESULT_TOP

# Build the toolchain.  Takes a couple hours and a couple gigabytes.
eval `cat powerpc-860.dat gcc-2.95.3-glibc-2.2.5.dat`  sh all.sh --notest

echo Done.


The cross compiler built, but then bombs when it is used:

powerpc-860-linux-gnu-gcc  nsswitch.c -c -O -Wall -Winline
-Wstrict-prototypes -
Wwrite-strings -mnew-mnemonics      -I../include -I.
-I/cygdrive/g/archive/apps/
crosstool/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.5/
buil
d-glibc/nss -I.. -I../libio
-I/cygdrive/g/archive/apps/crosstool/crosstool-0.38
/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.5/build-glibc
-I../sysdeps/pow
erpc/elf -I../linuxthreads/sysdeps/unix/sysv/linux
-I../linuxthreads/sysdeps/pth
read -I../sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv
-I../linuxthreads/
sysdeps/unix -I../linuxthreads/sysdeps/powerpc
-I../sysdeps/unix/sysv/linux/powe
rpc -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common
-I../
sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv
-I../sysdeps/uni
x/powerpc -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/powerpc
-I../sysdeps
/wordsize-32 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64
-I../sysdep
s/powerpc/soft-fp -I../sysdeps/ieee754 -I../sysdeps/generic/elf
-I../sysdeps/gen
eric  -nostdinc -isystem
/cygdrive/g/archive/apps/crosstool/crosstool-0.38/build
/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.5/gcc-core-prefix/lib/gcc-lib/po
werp
c-860-linux-gnu/2.95.3/include -isystem
/opt/crosstool/gcc-2.95.3-glibc-2.2.5/po
werpc-860-linux-gnu/powerpc-860-linux-gnu/include -D_LIBC_REENTRANT -include
../
include/libc-symbols.h     -o
/cygdrive/g/archive/apps/crosstool/crosstool-0.38/
build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.5/build-glibc/nss/nsswitch.
o
powerpc-860-linux-gnu-gcc: Internal compiler error: program cc1 got fatal
signal
 11
make[2]: ***
[/cygdrive/g/archive/apps/crosstool/crosstool-0.38/build/powerpc-86
0-linux-gnu/gcc-2.95.3-glibc-2.2.5/build-glibc/nss/nsswitch.o] Error 1
make[2]: Leaving directory
`/cygdrive/g/archive/apps/crosstool/crosstool-0.38/bu
ild/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.5/glibc-2.2.5/nss'
make[1]: *** [nss/subdir_lib] Error 2
make[1]: Leaving directory
`/cygdrive/g/archive/apps/crosstool/crosstool-0.38/bu
ild/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.5/glibc-2.2.5'
make: *** [all] Error 2
  
Any insights or speculations much appreciated,
Alex

-----Original Message-----
From: crossgcc-owner@sourceware.org [mailto:crossgcc-owner@sourceware.org]
On Behalf Of Dave Korn
Sent: Wednesday, January 04, 2006 10:33 AM
To: 'Alex Holland'; crossgcc@sources.redhat.com
Subject: RE: GCC 2.95.2 crosscompile broke under latest Cygwin

Alex Holland wrote:
> Hi!
> 
> Can anyone shed light on the following problem?
> 
> I updated Cygwin recently and my old, but working GCC 2.95.2, binutils
> 2.10 powerpc crosscompile toolchain, now no longer works. Compiling
> anything results in:
> 
> g++: Internal compiler error: program cpp got fatal signal 11
> 
> I tried generating a new GCC 2.95.3 toolchain using crosstool, but the
> build ultimately dies with the same error when it attempts to use the
> generated cross compiler. I tried to reinstall an earlier Cygwin version,
> but the oldest version still supported by the Cygwin setup caused the
> same error. 
> 
> I would update to newer tools, but I have an old in-circuit emulator and
> software debugger that is a nice tool, but only compatible with GCC 2.95.
> It comes from a company now owned by Wind River, so any new updates or
> support for this tool would cost thousands that I would like to avoid.
> 
> Any insight would be much appreciated.
> Alex


  I'm not 100% certain, but I reckon it's cpp that's doing it!

  Ok, you've updated the cygwin dll, and there's been some incompatible
changes (it's such a long time ago!), and now the old executables from the
toolchain don't work with your more recent cygwin.

  No problem; as you guessed, rebuilding the compiler using the new dll
should
solve that problem.  So why doesn't it?

  My guess is that the problem is that you had an installation of 2.95.2 for
your old dll, but when you rebuilt it you used 2.95.3 sources. That
shouldn't
matter, but it sometimes does, owing to a minor change between 2.95.2 and
2.95.3.

  Before 2.95.3, gcc had two *different* subprograms called cpp.  One lived
in
the lib/gcc/$target/$version subdirectory; it is the actual preprocessor
itself, and intended only for internal use by the compiler, under control of
the gcc compiler driver.

  The second, however, lives in $prefix/$target/bin, and is a simplified
version of the gcc compiler driver, the purpose of which is to provide a
publicly-accessible front-end to the C preprocessor for other utilities to
use; the main thing it does is just add the '-E' flag and pass the
commandline
options on to the internal preprocessor.

  Now even though the files live in different directories, one of which (the
.../lib/gcc/... subdir) should never go anywhere near your $PATH, it's just
a
bad and risky idea to have two very different programs kicking about with
the
same name.  Begging for confusion.  So in between 2.95.2 and 2.95.3, the
decision was taken to rename the compiler's-internal-use-only version of the
preprocessor to 'cpp0'.  (The user-visible front end driver 'cpp' still
exists
and remains the same name to this day, but cpp0, the external preprocessor,
has now been entirely removed, and the preprocessor has been built-in to the
compiler itself).

  So what I reckon happened is that when you rebuilt and installed 2.95.3,
everything got updated to the new versions, except for one thing: the new
preprocessor executable (the one for compiler's internal use in
.../lib/gcc/...) was named 'cpp0', so it didn't overwrite the old one, which
was just named 'cpp'.  And my bet now is that when the compiler attempts to
invoke 'cpp' to invoke the front-end to the preprocessor in order to
preprocess a source file, it is picking up and executing that old one,
rather
than the new one, because it lives in the same private subdir as the
compiler
(cc1.exe) itself, and so effectively you're still trying to run an
executable
that was compiled for the old version of the dll.

  The solution should be as simple as cd'ing into
$(WIND_BASE)/lib/gcc-lib/powerpc-wrs-vxworks/2.95.3, and move
aside/rename/delete the old, bad 'cpp.exe', leaving only the new 'cpp0.exe'.

[ Boy, does this ever take me back...  it's been five years since I used to
mess with vxworks! :) ]

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com






------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com