13.6.2012 7:51, damodar.sonone kirjoitti:
Hi,
I have been trying to upgrade my gcc-4.4.0 to gcc-4.7.0 since last four
weeks& getting following error at build time.
My build environment is:
------------------------
Platform: Windows-7 (32-bit) Cygwin
Binutils for Target: binutils-2.22 (which I upgraded from
binutils-version-2.21 by following the steps in
http://www.linuxforu.com/2010/01/binutils-porting-guide-to-a-new-target-architecture/
Is Cygwin "a new target architecture" ? I don't think so!
Prerequisites for GCC:
----------------------
Cygwin Package Information
Package Version Status
gmp 4.3.2-1 OK
mpfr 3.0.1-1 OK
ppl 0.10.2-1 OK
-------------------------------------
Step1: Download GCC-4.7.0 from http://gcc.gnu.org/releases.html
Step2: Extract GCC-4.7.0 in toplevel gcc-directory
Step3: create gcc-install& gcc-build directories in toplevel gcc-directory
Step4: Modify config.sub& config.gcc for target specific changes
What on earth these "target specific changes" are? Should Cygwin
really require some extra patches? I thought it being one of the
most common $host and $target systems for native and cross compilers...
Step5: Add target-folder containg target.md,target.h,target.c in gcc/config/
path (copied from<gcc-4.4.0/gcc/config/>)
???? Copying gcc-4.4.0 specific config files to gcc-4.7.0 sources
sounds insane...
Step6: Configure with following options in gcc-build path-
./gcc-4.7.0/./configure --target=my_target --program-prefix=my_target-
--prefix=/path to /gcc-install/ --enable-languages="c" --enable-checking
--with-ld=<path to binutils-v2.22/bin/my_target-ld.exe> --with-as=<path to
binutils-v2.22/bin/my_target-as.exe> CFLAGS="-g -O2 -I</path to
gcc-4.7.0/gcc/config/my_target"> --disable-shared --disable-decimal-float
--disable-threads --disable-libmudflap --disable-libssp --disable-libgomp
A simple question: Did you want it to be a native or a cross GCC? If
the "my_target" for $target gives a different result from the one
calculated for $host, then you will get a cross GCC, Cygwin/a-X-Cygwin/b
otherwise a native GCC...
Some time ago I tried gcc-4.7.0 for MinGW with Java as a cross and as a
native GCC, here the cross one with binutils-2.22.52.0.1 :
[root@HP-Pavilion bin]# i586-mingw32-gcc-4.7 -v
Using built-in specs.
COLLECT_GCC=i586-mingw32-gcc-4.7
COLLECT_LTO_WRAPPER=/media/2c439158-ef3e-4dcf-a63b-03191c302829/opt/cross/bin/../lib/gcc/i586-mingw32/4.7.0/lto-wrapper
Target: i586-mingw32
Configured with: ../configure --build=i686-linux-gnu
--host=i686-linux-gnu --target=i586-mingw32
--enable-languages=c,c++,java --prefix=/opt/cross
--libexecdir=/opt/cross/lib --enable-shared --enable-libstdcxx-debug
--enable-libgomp --enable-libgcj --enable-version-specific-runtime-libs
--disable-sjlj-exceptions --disable-win32-registry --disable-nls
--with-dwarf2 --with-gxx-include-dir=/opt/cross/include/c++/4.7.0
--program-prefix=i586-mingw32- --program-suffix=-4.7
Thread model: win32
gcc version 4.7.0 (by Kai Ruottu)
[root@HP-Pavilion bin]# i586-mingw32-ld -V
GNU ld (Linux/GNU Binutils) 2.22.52.0.1.20120131
Supported emulations:
i386pe
And the secondary (also) cross GCC for MinGW host & target built with
the primary gcc-4.7.0 for Linux host and MinGW target :
C:\opt\cross\bin>i586-mingw32-gcc-4.7 -v
Using built-in specs.
COLLECT_GCC=i586-mingw32-gcc-4.7
COLLECT_LTO_WRAPPER=c:/opt/cross/bin/../lib/gcc/i586-mingw32/4.7.0/lto-wrapper.exe
Target: i586-mingw32
Configured with: ../configure --build=i686-linux-gnu --host=i686-mingw32
--target=i586-mingw32 --enable-languages=c,c++,java --prefix=/opt/cross
--libexecdir=/opt/cross/lib --disable-sjlj-exceptions --with-dwarf2
--enable-shared --disable-win32-registry --disable-nls --enable-libgomp
--enable-libgcj --enable-libstdcxx-debug
--enable-version-specific-runtime-libs
--with-gxx-include-dir=/opt/cross/include/c++/4.7.0
--program-prefix=i586-mingw32- --program-suffix=-4.7
Thread model: win32
gcc version 4.7.0 (by Kai Ruottu)
As can be seen $host != $target so this was made as a cross GCC !
(Cross)Producing MinGW-targeted binutils seemed to be a big problem,
all the final '.exe's had the same size and none of them worked :-(
So I used the old ones with this GCC too :
C:\opt\cross\i586-mingw32\bin>ld -V
GNU ld (Linux/GNU Binutils) 2.17.50.0.16.20070511
Supported emulations:
i386pe
My guess is the usual one-eyeness in the DOS-world, for the people
working there is only one possible $build system : DOS, Windoze, OS/2
or something else from the non-*nix group :-( So there was some weird
extra option for the linker, probably when the target was MinGW or
Cygwin on Windoze. Meaning that :
1. when the target is MinGW or Cygwin
2. then the host system must be MinGW or Cygwin too
3. and then the build system must be MinGW or Cygwin too
4. and there cannot be any other GCCs, because there can
be only one GCC for Cygwin or MinGW, the native one
This attitude I call "one-eyeness" !!!!
OK, just forget all bullshitism and first try the pristine binutils-2.22
and gcc-4.7.0 sources from FSF before trying to "fix" something! "Don't
fix it if it ain't broken!" says the old rule... Altough there is my
name in the GCC output, I have fixed only the following place :
# Check whether --with-pkgversion was given.
if test "${with_pkgversion+set}" = set; then :
withval=$with_pkgversion; case "$withval" in
yes) as_fn_error "package version not specified" "$LINENO" 5 ;;
no) PKGVERSION= ;;
*) PKGVERSION="($withval) " ;;
esac
else
PKGVERSION="(by Kai Ruottu) "
fi
in the 'gcc/configure', nothing else, this was a SERIOUS bug when one
didn't see who the BAMF builder was :-) Without the --with-pkgversion,
one saw it missing before first trying the result :-(
