[Bug lto/39317] [lto] - cannot compute suffix of object files - cannot represent relocation type BFD_RELOC_64
--- Comment #10 from bje at gcc dot gnu dot org 2009-07-09 05:52 --- (In reply to comment #8) > I tried with the 'trunk' (instead of 'lto') and found the same issue. I really don't think this is a bug with the lto branch. If you still think it's a problem on trunk, then please re-open this bug as being against the trunk compiler. Thanks. -- bje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39317
[Bug lto/39317] [lto] - cannot compute suffix of object files - cannot represent relocation type BFD_RELOC_64
--- Comment #9 from rob1weld at aol dot com 2009-03-06 11:07 --- (In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) After the workaround we get 10 failures on i686 and 33 failures on x86_64 when compiling trunk revision 144629, results here: Results for 4.4.0 20090304 (experimental) [trunk revision 144629] (GCC) testsuite on i686-pc-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg00511.html Results for 4.4.0 20090304 (experimental) [trunk revision 144629] (GCC) testsuite on x86_64-unknown-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg00598.html Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39317
[Bug lto/39317] [lto] - cannot compute suffix of object files - cannot represent relocation type BFD_RELOC_64
--- Comment #8 from rob1weld at aol dot com 2009-03-05 22:59 ---
(In reply to comment #7)
> (In reply to comment #6)
> > Broken: x86_64-pc-linux-gnu
> > Works: i686-pc-linux-gnu
> > Rob
> Here is someone who had much better luck on 64-Bit (ia64-suse-linux-gnu):
> Results for 4.4.0 20090218 (experimental) [lto revision 144462] (lto merged
> with rev 144262) testsuite on ia64-suse-linux-gnu
> http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02766.html
> Rob
I tried with the 'trunk' (instead of 'lto') and found the same issue.
Here is my Host Compiler and the head of it's 'spec':
# gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1)
# gcc -dumpspecs 2>&1 | head -2
*asm:
%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*} %{m32:--32}
%{m64:--64}
The workaround that I applied enabled me to compile gcc _without_ making
any changes to the source code. I utilized a bit of spec file magic
and a bit of Environment trickery.
1. Build and install gmp / mpfr in default location.
2. Set LD_LIBRARY_PATH=/usr/local/lib
3. Build gcc and it will fail here:
checking for suffix of object files... configure: error: in
`/mnt/drive2/gcc_build_64/x86_64-unknown-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
...
The config.log will say:
/tmp/cc21sHKa.s:35: Error: cannot represent relocation type BFD_RELOC_64
4. Fix your "../gcc_build/gcc/specs" file so the top two lines are this:
*asm:
%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*} %{m32:--32}
%{!m32:%{!m64:--64}} %{!mno-sse2avx:%{mavx:-msse2avx}}
%{msse2avx:%{!mavx:-msse2avx}}
(You may need to adjust it to suit your ./configure options. The important
part is to change "%{m64:--64}" to "%{!m32:%{!m64:--64}}" ).
5. Continue the make and it will fail here:
checking for x86_64-unknown-linux-gnu-gcc...
/mnt/drive2/gcc_build_64/./gcc/xgcc -B/mnt/drive2/gcc_build_64/./gcc/
-B/mnt/drive2/gcc_installed_64/x86_64-unknown-linux-gnu/bin/
-B/mnt/drive2/gcc_installed_64/x86_64-unknown-linux-gnu/lib/ -isystem
/mnt/drive2/gcc_installed_64/x86_64-unknown-linux-gnu/include -isystem
/mnt/drive2/gcc_installed_64/x86_64-unknown-linux-gnu/sys-include
checking for suffix of object files... configure: error: in
`/mnt/drive2/gcc_build_64/x86_64-unknown-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
...
This time the config.log will not seem to indicate the problem but if
you add a "-v" to the gcc command that fails you will see that 'cc1'
is looking for "libgmp" in /usr/local/lib . If you use the "file"
command on 'xgcc' or the new 'cc1' you will find that they are 64-Bit
executables. Set 'LD_LIBRARY_PATH=/usr/local/lib64' and re-make.
6. When stage2 finishes and everything is moved to prev-gcc check
that you don't loose you 'spec' setting of "%{!m32:%{!m64:--64}}"
or you will need to type "make" again.
The build will complete without further intervention and without
having made any alterations to the trunk source code.
I "grepped the trunk" and found that some parts of some scripts do check
if one is using "LD_LIBRARY_PATH_32" and "LD_LIBRARY_PATH_64" but these
'unofficial' (and useful) Environment Variables are not used in all parts
of the gcc build -- thus the need to hand-alter your "LD_LIBRARY_PATH" as
the compiler second-stages itself and converts from a 32-Bit gcc (your
Host Compiler) and becomes a full-fledged 64-Bit executable.
Solution:
If the Makefile's "$(SPECS)" target would check that the dumpspecs
it is getting (from a prior version of gcc (the Host Compiler)) is
compatible with a 64 bit build (and fix it if needed) _and_ if
the scripts / Makefiles would toss a "64" on the tail of any
"LD_LIBRARY_PATH" paths as the compiler evolves from 32 to 64 bit
then it would all work without any intervention.
I'll leave it to _others_ to decide if gcc < 4.4.x is a Regression for
not having their spec files suitable to build later revisions of gcc.
This revision of gcc (4.4.x) needs a 'sed' script to rewrite the 'spec'
file and do sanity checking. The scripts also need to 'promote' the
library directory path from 32 to 64 as the Compiler changes it's strips.
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39317
[Bug lto/39317] [lto] - cannot compute suffix of object files - cannot represent relocation type BFD_RELOC_64
--- Comment #7 from rob1weld at aol dot com 2009-03-02 03:19 --- (In reply to comment #6) > Broken: x86_64-pc-linux-gnu > Works: i686-pc-linux-gnu > Rob Here is someone who had much better luck on 64-Bit (ia64-suse-linux-gnu): Results for 4.4.0 20090218 (experimental) [lto revision 144462] (lto merged with rev 144262) testsuite on ia64-suse-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02766.html Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39317
[Bug lto/39317] [lto] - cannot compute suffix of object files - cannot represent relocation type BFD_RELOC_64
--- Comment #6 from rob1weld at aol dot com 2009-02-28 17:34 --- I rebooted Debian and chose the 32-bit Kernel, then re-configured in an _identical_ manner. I rebuilt gcc (using un-modified source) with no extra effort with the 32-Bit Kernel. Host Compiler: # gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) Broken on 64-bit: # gcc/xgcc -v Using built-in specs. COLLECT_GCC=gcc/xgcc Target: x86_64-pc-linux-gnu Configured with: ../lto_trunk/configure --prefix=/usr/local/lto --enable-languages=lto,c++ --enable-multilib --disable-stage1-checking --enable-checking=release --with-gmp=/usr/local --with-mpfr=/usr/local Thread model: posix gcc version 4.4.0 20090218 (experimental) [lto revision 144460] (lto merged with rev 144262) Works on 32-bit: # gcc/xgcc -v Using built-in specs. COLLECT_GCC=gcc/xgcc Target: i686-pc-linux-gnu Configured with: ../lto_trunk/configure --prefix=/usr/local/lto --enable-languages=lto,c++ --enable-multilib --disable-stage1-checking --enable-checking=release --with-gmp=/usr/local --with-mpfr=/usr/local Thread model: posix gcc version 4.4.0 20090218 (experimental) [lto revision 144460] (lto merged with rev 144262) Broken: x86_64-pc-linux-gnu Works: i686-pc-linux-gnu Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39317
[Bug lto/39317] [lto] - cannot compute suffix of object files - cannot represent relocation type BFD_RELOC_64
--- Comment #5 from rob1weld at aol dot com 2009-02-28 03:53 ---
(In reply to comment #4)
> In addition to the lack of "-L..." this is also a 'spec' issue :
> ...
The issue with the spec file is caused by this in the Makefile.in:
# Dump a specs file to make -B./ read these specs over installed ones.
$(SPECS): xgcc$(exeext)
$(GCC_FOR_TARGET) -dumpspecs > tmp-specs
mv tmp-specs $(SPECS)
Debian's supplied gcc 4.3 is built androgynous:
# gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1)
# gcc -dumpspecs | head -2
*asm:
%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*} %{m32:--32}
%{m64:--64}
We need to check that the host-compiler's "spec" is correct and fix it.
Here is some pseudo-code:
if ' gcc -dumpspecs | grep \{m32:--32 | grep \{m64:--64 ' then # not correct
if test x`(hostname || uname -n) 2>/dev/null | sed 1q` == "xopensolaris" ;
then
if 'isainfo -k' = 'i386' then
gcc -dumpspecs | sed 2s/m32:--32/!m32:--32/1p
fi
if 'isainfo -k' = 'amd_64' | 'x86_64' then
gcc -dumpspecs | sed 2s/m64:--64/!m64:--64/1p
fi
else # Not OpenSolaris' uname
if 'uname -m' = 'i386' then
gcc -dumpspecs | sed 2s/m32:--32/!m32:--32/1p
fi
if 'uname -m' = 'amd_64' | 'x86_64' then
gcc -dumpspecs | sed 2s/m64:--64/!m64:--64/1p
fi
fi
fi
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39317
[Bug lto/39317] [lto] - cannot compute suffix of object files - cannot represent relocation type BFD_RELOC_64
--- Comment #4 from rob1weld at aol dot com 2009-02-27 06:08 ---
# uname -m
x86_64
In addition to the lack of "-L..." this is also a 'spec' issue :
Original (head -2 ../lto_build/prev-gcc/specs) :
*asm:
%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*} %{m32:--32}
%{m64:--64} %{!mno-sse2avx:%{mavx:-msse2avx}} %{msse2avx:%{!mavx:-msse2avx}}
Fixed:
*asm:
%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*} %{m32:--32}
%{!m64:--64} %{!mno-sse2avx:%{mavx:-msse2avx}} %{msse2avx:%{!mavx:-msse2avx}}
If I am:
# uname -m
x86_64
I need the "!" before the "m64".
If I am:
# uname -m
i386
I need the "!" before the "m32".
That defaults the compiler to build executables that match the
Boot-mode (32 or 64 bit). To build in the mode _not_ booted into
should require the appropriate "-m64" _OR_ "-m32". We should not
be required to _always_ specify either "-m64" _OR_ "-m32", there
must be a default.
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39317
[Bug lto/39317] [lto] - cannot compute suffix of object files - cannot represent relocation type BFD_RELOC_64
--- Comment #3 from rob1weld at aol dot com 2009-02-27 01:29 --- I'm running Debian Lenny 5.0 released 14 Feb 2009, with updates. # ld --version GNU ld (GNU Binutils for Debian) 2.18.0.20080103 # as --version GNU assembler (GNU Binutils for Debian) 2.18.0.20080103 Simply tossing in an -m64 alerts us to another issue: # /usr/src/lto_build/./gcc/xgcc -B/usr/src/lto_build/./gcc/ -B/usr/local/lto/x86_64-unknown-linux-gnu/bin/ -B/usr/local/lto/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/lto/x86_64-unknown-linux-gnu/include -isystem /usr/local/lto/x86_64-unknown-linux-gnu/sys-include -o conftest -g -O2 -m64 test_delete.c /usr/bin/ld: crtbegin.o: No such file: No such file or directory collect2: ld returned 1 exit status but (with the default installation of Debian's gcc version 4.3.2 (Debian 4.3.2-1.1) ), a workaround is to add this to the file ../lto_trunk/libgcc/configure: -m64 -L/usr/lib/gcc/i486-linux-gnu/4.3/64 That ensures we can access crt*.o and libgcc*, etc., for Linking. Once I get it built, for the first time on this Platform, I will go back and determine correct fixes and try to produce cross-Platform compatible patches. Thanks, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39317
[Bug lto/39317] [lto] - cannot compute suffix of object files - cannot represent relocation type BFD_RELOC_64
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-02-27 00:34 --- What as version are you using? This looks like a bug in the GNU binutils rather than in GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39317
[Bug lto/39317] [lto] - cannot compute suffix of object files - cannot represent relocation type BFD_RELOC_64
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-27 00:33 --- This is unrelated to those bug reports. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39317
