From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 633 invoked by alias); 13 Jun 2012 11:45:38 -0000 Received: (qmail 620 invoked by uid 22791); 13 Jun 2012 11:45:37 -0000 X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL,BAYES_50,KHOP_THREADED,TW_CX,TW_DC,TW_GC,TW_GX,TW_JL,TW_KG X-Spam-Check-By: sourceware.org Received: from wmh1.mail.saunalahti.fi (HELO wmh1.mail.saunalahti.fi) (62.142.5.133) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 13 Jun 2012 11:45:22 +0000 Received: from [192.168.0.43] (dsl-kmibrasgw1-fec7f800-208.dhcp.inet.fi [84.248.199.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kai.ruottu@wippies.com) by wmh1.mail.saunalahti.fi (Postfix) with ESMTPSA id E7FEF1FC074 for ; Wed, 13 Jun 2012 14:45:18 +0300 (EEST) Message-ID: <4FD87E5C.6060207@wippies.com> Date: Wed, 13 Jun 2012 11:45:00 -0000 From: Kai Ruottu User-Agent: Mozilla/5.0 (Windows NT 5.0; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: gcc-help@gcc.gnu.org Subject: Re: upgrading gcc-4.4.0 to gcc-4.7.0:configure: error: cannot compute suffix of object files: cannot compile References: <34003613.post@talk.nabble.com> In-Reply-To: <34003613.post@talk.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2012-06/txt/msg00120.txt.bz2 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) ???? 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= --with-as= binutils-v2.22/bin/my_target-as.exe> CFLAGS="-g -O2 -I 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 :-(