public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
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.

      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).