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