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

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

[damodar.sonone]

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/
)
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
Step5: Add target-folder containg target.md,target.h,target.c in gcc/config/
path (copied from <gcc-4.4.0/gcc/config/>)
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

Configure result:
-----------------
<snip>
checking where to find the target ar... pre-installed
checking where to find the target as... pre-installed
checking where to find the target cc... just compiled
checking where to find the target c++... pre-installed
checking where to find the target c++ for libstdc++... pre-installed
checking where to find the target dlltool... pre-installed
checking where to find the target gcc... just compiled
checking where to find the target gcj... pre-installed
checking where to find the target gfortran... pre-installed
checking where to find the target gccgo... pre-installed
checking where to find the target ld... pre-installed
checking where to find the target lipo... pre-installed
checking where to find the target nm... pre-installed
checking where to find the target objdump... pre-installed
checking where to find the target ranlib... pre-installed
checking where to find the target readelf... pre-installed
checking where to find the target strip... pre-installed
checking where to find the target windres... pre-installed
checking where to find the target windmc... pre-installed
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether -fkeep-inline-functions is supported... yes
configure: creating ./config.status
config.status: creating Makefile
<snip>

Step7: run make
Step8: Resolve errors related to macros 
Step9: run make again 
Make Result:
------------
<snip>
checking for suffix of object files... configure: error: in `/path to
build_my_target/my_target/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
Makefile:9282: recipe for target `configure-target-libgcc' failed
make[1]: *** [configure-target-libgcc] Error 1
make[1]: Leaving directory `/my path/gcc_build'
Makefile:853: recipe for target `all' failed
make: *** [all] Error 2
<snip>


I have tried all the steps mentioned in several posts to resolve this issue,
like setting the LD_LIBRARY_PATH and re-installing all the packages which
are installed as per Prerequisites for GCC.
Any pointers to fix this issue are very much appreciated.


-- 
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-tp34003613p34003613.html
Sent from the gcc - Help mailing list archive at Nabble.com.

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

[Ian Lance Taylor]

"damodar.sonone" <dsonone@gmail.com> writes:

> checking for suffix of object files... configure: error: in `/path to
> build_my_target/my_target/libgcc':
> configure: error: cannot compute suffix of object files: cannot compile
> See `config.log' for more details.

What do you see in the file /path to
build_my_target/my_target/libgcc/config.log?

Ian

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

[damodar.sonone]

There are several "errors" in config.log file, most of which I observed even
when the GCC-4.4.0 build successfully. I do not know how to resolve all of
these errors.
-------------------------------
Config.log in libgcc folder:
-------------------------------
<snip1>
configure:6421: checking for uchar
configure:6440: gcc -c -g -O2 -I/<path to
gcc-4.7.0/gcc/config/my_target>conftest.c >&5
conftest.c: In function 'main':
conftest.c:75:6: error: 'uchar' undeclared (first use in this function)
conftest.c:75:6: note: each undeclared identifier is reported only once for
each function it appears in
conftest.c:75:13: error: expected expression before ')' token
configure:6440: $? = 1
configure: failed program was:
--------------------------- lost of macros included here---------
 /* end confdefs.h.  */
#include <sys/types.h>

int
main ()
 {
 if ((uchar *)0) return 0;

 if (sizeof(uchar)) return 0;
   ;
   return 0;
 }
<snip1>
<snip2>
conftest.c: In function 'main':
conftest.c:99:10: error: 'fwrite_unlocked' undeclared (first use in this
function)
conftest.c:99:10: note: each undeclared identifier is reported only once for
each function it appears in
configure:5961: $? = 1
<snip2>
<snip3>
similar errors for
'fputc_unlocked','fread_unlocked''fprintf_unlocked''fileno_unlocked'
'fgets_unlocked'
'fgetc_unlocked''fflush_unlocked''ferror_unlocked''feof_unlocked''clearerr_unlocked''errno'
'basename'
<snip3>
<snip4>
configure:5549: checking for obstacks
configure:5570: gcc -o conftest.exe -g -O2 -I<path to
gcc-4.7.0/gcc/config/my_target>   -Wl,--stack,12582912 conftest.c  >&5
conftest.c:68:29: fatal error: obstack.h: No such file or directory
compilation terminated.
configure:5570: $? = 1
configure: failed program was:
<snip4>

<snip5>
configure:4285: checking minix/config.h usability
configure:4285: gcc -c -g -O2 -I<path to gcc-4.7.0/gcc/config/my_target>
conftest.c >&5
Conftest.c:52:26: fatal error: minix/config.h: No such file or directory
compilation terminated.
configure:4285: $? = 1
configure: failed program was:
<snip5>

Could you please point out what is missing?


Ian Lance Taylor-3 wrote:
> 
> "damodar.sonone" <dsonone@gmail.com> writes:
> 
>> checking for suffix of object files... configure: error: in `/path to
>> build_my_target/my_target/libgcc':
>> configure: error: cannot compute suffix of object files: cannot compile
>> See `config.log' for more details.
> 
> What do you see in the file /path to
> build_my_target/my_target/libgcc/config.log?
> 
> Ian
> 
> 

-- 
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-tp34003613p34003766.html
Sent from the gcc - Help mailing list archive at Nabble.com.

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

[damodar.sonone]

Hello,
sorry, the previous log was from "libcpp folder" under gcc-build & below is
the error log from config.log file from libgcc folder.

-------------------------------
Config.log in libgcc folder:
-------------------------------
<snip1>
xgcc: error: unrecognized command line option '-V'
xgcc: fatal error: no input files
compilation terminated.
configure:3418: $? = 1
<snip1>
<snip2>
conftest.c: In function 'main':
conftest.c:16:1: internal compiler error: in reg_save_code, at
caller-save.c:158
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
configure:3437: $? = 1
configure:3625: checking for suffix of object files
<snip2>

Please suggest what is missing.

<quoe author="damodar.sonone">
There are several "errors" in config.log file, most of which I observed even
when the GCC-4.4.0 build successfully. I do not know how to resolve all of
these errors.
-------------------------------
Config.log in libgcc folder:
-------------------------------
<snip1>
configure:6421: checking for uchar
configure:6440: gcc -c -g -O2 -I/<path to
gcc-4.7.0/gcc/config/my_target>conftest.c >&5
conftest.c: In function 'main':
conftest.c:75:6: error: 'uchar' undeclared (first use in this function)
conftest.c:75:6: note: each undeclared identifier is reported only once for
each function it appears in
conftest.c:75:13: error: expected expression before ')' token
configure:6440: $? = 1
configure: failed program was:
--------------------------- lost of macros included here---------
 /* end confdefs.h.  */
#include <sys/types.h>

int
main ()
 {
 if ((uchar *)0) return 0;

 if (sizeof(uchar)) return 0;
   ;
   return 0;
 }
<snip1>
<snip2>
conftest.c: In function 'main':
conftest.c:99:10: error: 'fwrite_unlocked' undeclared (first use in this
function)
conftest.c:99:10: note: each undeclared identifier is reported only once for
each function it appears in
configure:5961: $? = 1
<snip2>
<snip3>
similar errors for
'fputc_unlocked','fread_unlocked''fprintf_unlocked''fileno_unlocked'
'fgets_unlocked'
'fgetc_unlocked''fflush_unlocked''ferror_unlocked''feof_unlocked''clearerr_unlocked''errno'
'basename'
<snip3>
<snip4>
configure:5549: checking for obstacks
configure:5570: gcc -o conftest.exe -g -O2 -I<path to
gcc-4.7.0/gcc/config/my_target>   -Wl,--stack,12582912 conftest.c  >&5
conftest.c:68:29: fatal error: obstack.h: No such file or directory
compilation terminated.
configure:5570: $? = 1
configure: failed program was:
<snip4>

<snip5>
configure:4285: checking minix/config.h usability
configure:4285: gcc -c -g -O2 -I<path to gcc-4.7.0/gcc/config/my_target>
conftest.c >&5
Conftest.c:52:26: fatal error: minix/config.h: No such file or directory
compilation terminated.
configure:4285: $? = 1
configure: failed program was:
<snip5>

Could you please point out what is missing?


Ian Lance Taylor-3 wrote:
> 
> "damodar.sonone" <dsonone@gmail.com> writes:
> 
>> checking for suffix of object files... configure: error: in `/path to
>> build_my_target/my_target/libgcc':
>> configure: error: cannot compute suffix of object files: cannot compile
>> See `config.log' for more details.
> 
> What do you see in the file /path to
> build_my_target/my_target/libgcc/config.log?
> 
> Ian
> 
> 



-- 
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-tp34003613p34003806.html
Sent from the gcc - Help mailing list archive at Nabble.com.

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

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

[damodar.sonone]

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.

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

[Ian Lance Taylor]

"damodar.sonone" <dsonone@gmail.com> writes:

> conftest.c: In function 'main':
> conftest.c:16:1: internal compiler error: in reg_save_code, at
> caller-save.c:158
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.

This one is the problem.

It means that your newly built compiler has a bug--it gets an internal
compiler error.  Unfortunately I don't have a simple solution here.  I
don't know why such an error would occur for you, when it clearly
doesn't happen for other people.

Ian

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

[Deepti Sharma]

After battling with this error for several hours, I was able to resolve this
error simply by putting my nop instruction pattern as the first pattern.
Initially, I had movqi as my first instruction pattern. Is this some
restriction or a bug in gcc?

While debugging the source I found that the assertion "gcc_assert
(cached_reg_save_code[reg][mode]);" gets failed in reg_save_code(), which
implies that value returned by "cached_reg_save_code[reg][mode]" has to be
non-zero. 

Now, in reg_save_code(), cached_reg_save_code[reg][mode] gets its value from
"recog_memoized (saveinsn)" as:

---snip---
  cached_reg_save_code[reg][mode] = recog_memoized (saveinsn);
---snip---

Now, in file insn-recog.c generated during the build, I see that movqi has
got a number 0 returned by recog function:

---snip---
L2: ATTRIBUTE_UNUSED_LABEL
  if (general_operand (x1, QImode))
    {
      operands[1] = x1;
      return 0;  /* movqi */
    }
  x1 = XEXP (x0, 0);
  goto L4;
---snip---

If I place any other pattern before movqi, so that movqi gets a non-zero
value, I do not get the internal compiler error.

Could you please elaborate on this behaviour? I could not find any such
restriction in the gcc documentation.


Thanks,
Deepti



> -----Original Message-----
> From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
> Behalf Of Ian Lance Taylor
> Sent: 13 June 2012 23:01
> To: damodar.sonone
> Cc: 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
> 
> "damodar.sonone" <dsonone@gmail.com> writes:
> 
> > conftest.c: In function 'main':
> > conftest.c:16:1: internal compiler error: in reg_save_code, at
> > caller-save.c:158
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See <http://gcc.gnu.org/bugs.html> for instructions.
> 
> This one is the problem.
> 
> It means that your newly built compiler has a bug--it gets an internal
> compiler error.  Unfortunately I don't have a simple solution here.  I
> don't know why such an error would occur for you, when it clearly
> doesn't happen for other people.
> 
> Ian

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

[Ian Lance Taylor]

"Deepti Sharma" <deepti.gccretarget@gmail.com> writes:

> After battling with this error for several hours, I was able to resolve this
> error simply by putting my nop instruction pattern as the first pattern.
> Initially, I had movqi as my first instruction pattern. Is this some
> restriction or a bug in gcc?
> ...
> Could you please elaborate on this behaviour? I could not find any such
> restriction in the gcc documentation.

I don't know what the problem is because I don't have any detailed
information about the change you made to GCC.

There is nothing special about the first insn in the MD file.  The only
way in which ordering is important is that RTL patterns are matched
against insns in order.  It's normally a bug if two insns match an RTL
pattern, but there are unusual cases where that is desirable, and then
order matters.

Ian