upgrading gcc-4.4.0 to gcc-4.7.0:configure: error: cannot compute suffix of object files: cannot compile

[Kai Ruottu]

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 :-(