I'm trying to get a working gcc cross-compiler created that lives on my local machine [Darwin new-host-2.home 10.7.4 Darwin Kernel Version 10.7.4: Mon Apr 18 21:24:17 PDT 2011; root:xnu-1504.14.12~3/RELEASE_X86_64 x86_64] and targets a FreeBSD 8.2 x86_64 (AMD64 in FreeBSD terms) target.
I'm compiling gcc 4.3.1, binutils 2.19, GMP 4.2.3, MPFR 2.3.2.
I'm seeing a couple of things that could be going wrong, but they may be red herrings. For what it's worth I am taking known working scripts to build a cross compiler and simply trying to get them to work for x86_64 architecture, so I know I'm not out in left field..
I'm using the gcc compiler target "x86_64-pc-freebsd7" which seems correct. I use compiler flags of: compilerConfigureFlags="--enable-version-specific-runtime-libs --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit"
and I configure binutils using "--enable-64-bit-bfd"
In my final error; something that catches my attention is '-m32' which I'm not sure if it should be there. The error is because ld can't make sense out of my "incompatible" file /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/x86_64-pc-freebsd7/lib/libc.a when searching for -lc. When I run file
on libc.a and libc.so from the FreeBSD box I get:
sh-3.2# file /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/x86_64-pc-freebsd7/lib/libc.a/Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/x86_64-pc-freebsd7/lib/libc.a: current ar archive
sh-3.2# file /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/x86_64-pc-freebsd7/lib/libc.so /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/x86_64-pc-freebsd7/lib/libc.so: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, stripped
Final line my build dies on:
/Developer/Cocotron/1.0/build/FreeBSD/x86_64/gcc-4.3.1/./gcc/xgcc -B/Developer/Cocotron/1.0/build/FreeBSD/x86_64/gcc-4.3.1/./gcc/ -B/Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/x86_64-pc-freebsd7/bin/ -B/Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/x86_64-pc-freebsd7/lib/ -isystem /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/x86_64-pc-freebsd7/include -isystem /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/x86_64-pc-freebsd7/sys-include -O2 -O2 -g -m32 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -DNATIVE_CROSS -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -pthread -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o ./libgcc_s.so.1.tmp -O2 -g -m32 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o unwind-dw2_s.o unwind-dw2-fde_s.o unwind-sjlj_s.o gthr-gnat_s.o unwind-c_s.o emutls_s.o -lc && rm -f ./libgcc_s.so && if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && ln -s libgcc_s.so.1 ./libgcc_s.so /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/x86_64-pc-freebsd7/bin/ld: skipping incompatible /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/x86_64-pc-freebsd7/lib//libc.so when searching for -lc /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/x86_64-pc-freebsd7/bin/ld: skipping incompatible /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/x86_64-pc-freebsd7/lib/libc.a when searching for -lc /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/x86_64-pc-freebsd7/bin/ld: cannot find -lc collect2: ld returned 1 exit status make[2]: *** [libgcc_s.so] Error 1 make[1]: *** [all-target-libgcc] Error 2 make: *** [all] Error 2
I'm surprised ld can't handle it, because when I run this version of 'ld' I get the followig output:
/Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/x86_64-pc-freebsd7/bin/ld: supported targets: elf64-x86-64-freebsd elf32-i386-freebsd coff-i386 efi-app-ia32 efi-bsdrv-ia32 efi-rtdrv-ia32 efi-app-x86_64 efi-bsdrv-x86_64 efi-rtdrv-x86_64 elf32-i386 elf64-x86-64 elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary ihex /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/x86_64-pc-freebsd7/bin/ld: supported emulations: elf_x86_64_fbsd elf_i386_fbsd elf_x86_64 elf_i386 /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/x86_64-pc-freebsd7/bin/ld: emulation specific options: elf_x86_64_fbsd:
Which indicates to me that I've built the binutils correctly.. yet that can't handle a library that's an ELF 64-bit x86-64 FreeBSD shared object??
To give the story from the start - compiling binutils is flawless it seems.
Compiling GMP and MPFR both give me some ranlib issues that worry me a bit, trying to build up a .a library but the .o files have no symbols.. this could be normal but I can't tell?
GMP:
/usr/bin/ranlib: file: .libs/libprintf.a(obprintf.o) has no symbols /usr/bin/ranlib: file: .libs/libprintf.a(obvprintf.o) has no symbols /usr/bin/ranlib: file: .libs/libprintf.a(obprntffuns.o) has no symbols /usr/bin/ranlib: file: .libs/libprintf.a(repl-vsnprintf.o) has no symbols ranlib .libs/libprintf.a ranlib: file: .libs/libprintf.a(obprintf.o) has no symbols ranlib: file: .libs/libprintf.a(obvprintf.o) has no symbols ranlib: file: .libs/libprintf.a(obprntffuns.o) has no symbols ranlib: file: .libs/libprintf.a(repl-vsnprintf.o) has no symbols
And I get some more further along..
ranlib /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/lib/libgmp.a ranlib: file: /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/lib/libgmp.a(mp_clz_tab.o) has no symbols ranlib: file: /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/lib/libgmp.a(obprintf.o) has no symbols ranlib: file: /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/lib/libgmp.a(obvprintf.o) has no symbols ranlib: file: /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/lib/libgmp.a(obprntffuns.o) has no symbols ranlib: file: /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/lib/libgmp.a(repl-vsnprintf.o) has no symbols
MPFR:
Similar deal:
/usr/bin/ranlib: file: .libs/libmpfr.a(volatile.o) has no symbols /usr/bin/ranlib: file: .libs/libmpfr.a(mp_clz_tab.o) has no symbols /usr/bin/ranlib: file: .libs/libmpfr.a(logging.o) has no symbols /usr/bin/ranlib: file: .libs/libmpfr.a(set_d64.o) has no symbols /usr/bin/ranlib: file: .libs/libmpfr.a(get_d64.o) has no symbols ranlib .libs/libmpfr.a ranlib: file: .libs/libmpfr.a(volatile.o) has no symbols ranlib: file: .libs/libmpfr.a(mp_clz_tab.o) has no symbols ranlib: file: .libs/libmpfr.a(logging.o) has no symbols ranlib: file: .libs/libmpfr.a(set_d64.o) has no symbols ranlib: file: .libs/libmpfr.a(get_d64.o) has no symbols creating libmpfr.la
And a bit further along..
ranlib /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/lib/libmpfr.a ranlib: file: /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/lib/libmpfr.a(volatile.o) has no symbols ranlib: file: /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/lib/libmpfr.a(mp_clz_tab.o) has no symbols ranlib: file: /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/lib/libmpfr.a(logging.o) has no symbols ranlib: file: /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/lib/libmpfr.a(set_d64.o) has no symbols ranlib: file: /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/lib/libmpfr.a(get_d64.o) has no symbols
Then we're on to GCC, presumably with good binutils, GMP, and MPFR.. but finally during build of gcc (specifically libgcc) I get the ld linking failure.
Some more supporting information:
I compile binutils using:
CFLAGS="-m32 -Wformat=0 -Wno-error=deprecated-declarations" $sourceFolder/binutils-$binutilsVersion/configure --prefix="$resultFolder" --target=$compilerTarget $binutilsConfigureFlags
However I encounter the same problem if I switch to -m64..
CFLAGS="-m64 -Wformat=0 -Wno-error=deprecated-declarations" $sourceFolder/binutils-$binutilsVersion/configure --prefix="$resultFolder" --target=$compilerTarget $binutilsConfigureFlags
I compile GMP and MPFR using:
ABI=32 $sourceFolder/gmp-$gmpVersion/configure --prefix="$resultFolder"
I compile GCC using:
CFLAGS="-m32" $sourceFolder/gcc-$gccVersion/configure -v --prefix="$resultFolder" --target=$compilerTarget \ --with-gnu-as --with-gnu-ld --with-headers=$resultFolder/$compilerTarget/include \ --without-newlib --disable-multilib --disable-libssp --disable-nls --enable-languages="$enableLanguages" \ --with-gmp=$buildFolder/gmp-$gmpVersion --enable-decimal-float --with-mpfr=$resultFolder --enable-checking=release \ --enable-objc-gc \
$compilerConfigureFlags
For all these, I'm using:
compilerTarget=x86_64-pc-freebsd7 compilerConfigureFlags="--enable-version-specific-runtime-libs --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit" binutilsConfigureFlags="--enable-64-bit-bfd"
On my target FreeBSD system, which by the way is standard FreeBSD 8.2 RELEASE amd64, ld indicates very similar capabilities to my cross-compiling one. In fact, it appears that my cross-compiling environment's ld handles a superset of what the actual target's ld handles - making me think I should be able to handle any files without the incompatibility I'm seeing
ld: supported targets: elf64-x86-64 efi-app-ia32 elf32-i386-freebsd srec symbolsrec tekhex binary ihex ld: supported emulations: elf_i386_fbsd elf_x86_64_fbsd ld: emulation specific options: elf_i386_fbsd:
-m32
is wrong. 32 bit object code and a 64 bit library can't be linked together. – Gunther Piez