From: "damodar.sonone" <dsonone@gmail.com>
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
Date: Wed, 13 Jun 2012 12:50:00 -0000 [thread overview]
Message-ID: <34005462.post@talk.nabble.com> (raw)
In-Reply-To: <4FD87E5C.6060207@wippies.com>
Kai Ruottu-3 wrote:
>
> 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!
>
> Sorry, it was misinterpreted, I am building a cross compiler. (host
> !=target)The target is an 8 bit processor "my_target"
>
>> 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...
>
> It is not the gcc 4.4.0 source files that I have touched. I have just
> copied the Machine description files of "my_target" (my_target.md,
> my_target.c, my_target.h) corresponding to gcc-4.4.0, to the latest
> gcc-4.7.0
>
>> 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...
>
> Its cross 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 :
>
> I have downloaded gcc-4.7.0 and binutils 2.22 from FSF only, and tried
> building it.
>
> # 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 :-(
>
>
--
View this message in context: http://old.nabble.com/upgrading-gcc-4.4.0-to-gcc-4.7.0%3Aconfigure%3A-error%3A-cannot-compute-suffix-of-object-files%3A-cannot-compile-tp34003613p34005462.html
Sent from the gcc - Help mailing list archive at Nabble.com.
prev parent reply other threads:[~2012-06-13 12:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-13 4:51 damodar.sonone
2012-06-13 5:09 ` Ian Lance Taylor
2012-06-13 6:04 ` damodar.sonone
2012-06-13 6:18 ` damodar.sonone
2012-06-13 17:31 ` Ian Lance Taylor
2012-06-20 5:34 ` Deepti Sharma
2012-06-20 5:44 ` Ian Lance Taylor
2012-06-13 11:45 ` Kai Ruottu
2012-06-13 12:50 ` damodar.sonone [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=34005462.post@talk.nabble.com \
--to=dsonone@gmail.com \
--cc=gcc-help@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).