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.
