Trouble building cross compilers

I have a couple of questions about cross compiling with gcc 3.0:

1) is it possible to build an x86 hosted gcc 3.0 ia64 cross compiler without nue? Or, which packages do I need to build a gcc cross compiler?
2) does an x86 hosted gcc 3.0 ia64 cross compiler generate different code than a native ia64 compiler? If so, how different is the generated code?

I'd like to have a gcc 3.0 cross compiler for the purpose of building kernels unless the cross compiler generated code differs enough from a natively built that I'm likely to run into bugs that I wouldn't otherwise.

In trying to do (1) to answer (2) for myself, I did the following on a Red Hat 6.2 x86 machine w/gcc-2.96 from 7.0 installed
a) built and installed binutils 2.12 (configured with --target=ia64-gnu-linux --prefix=/tmp/ia64-cross-3.0)
b) tried to build and install gcc 3.0 (configured with the same options as above), but with 'make LANGUAGES=c' instead of just 'make'

Unfortunately, I got hung up in the middle of step (b) with the errors shown below. IIRC, the Cygnus snapshot tarballs were 'cross-compile ready' in that they had all the necessary header files and utilities needed for a full cross development environment. Any notes on how those trees were built would be appreciated.

Thanks,
Jesse

/home/jbarnes/working/cross/gcc-build/gcc/xgcc -B/home/jbarnes/working/cross/gcc-build/gcc/ -B/tmp/ia64-cross-3.0/ia64-gnu-linux/bin/ -B/tmp/ia64-cross-3.0/ia64-gnu-linux/lib/ -isystem /tmp/ia64-cross-3.0/ia64-gnu-linux/include -O2 -DCROSS_COMPILE -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -g1 -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc-3.0/gcc -I../../gcc-3.0/gcc/. -I../../gcc-3.0/gcc/config -I../../gcc-3.0/gcc/../include -fexceptions -c ../../gcc-3.0/gcc/config/ia64/unwind-ia64.c -o libgcc/./unwind-ia64.o
In file included from ../../gcc-3.0/gcc/config/ia64/unwind-ia64.c:35:
../../gcc-3.0/gcc/unwind.h:169:20: stdlib.h: No such file or directory
In file included from ../../gcc-3.0/gcc/config/ia64/unwind-ia64.c:35:
../../gcc-3.0/gcc/unwind.h: In function `_Unwind_GetTextRelBase':
../../gcc-3.0/gcc/unwind.h:181: warning: implicit declaration of function `abort'
../../gcc-3.0/gcc/unwind.h:179: warning: unused parameter `_C'
../../gcc-3.0/gcc/config/ia64/unwind-ia64.c: In function `push':
../../gcc-3.0/gcc/config/ia64/unwind-ia64.c:234: warning: implicit declaration of function memcpy' ../../gcc-3.0/gcc/config/ia64/unwind-ia64.c: In function uw_frame_state_for':
../../gcc-3.0/gcc/config/ia64/unwind-ia64.c:1462: warning: implicit declaration of function memset' ../../gcc-3.0/gcc/config/ia64/unwind-ia64.c: In function uw_install_context':
../../gcc-3.0/gcc/config/ia64/unwind-ia64.c:1777: warning: passing arg 1 of `ia64_rse_skip_regs' makes pointer from integer without a cast ../../gcc-3.0/gcc/config/ia64/unwind-ia64.c:1777: warning: assignment makes integer from pointer without a cast ../../gcc-3.0/gcc/config/ia64/unwind-ia64.c: At top level:
../../gcc-3.0/gcc/config/ia64/unwind-ia64.c:1264: warning: ia64_rse_is_rnat_slot' defined but not used ../../gcc-3.0/gcc/config/ia64/unwind-ia64.c:1281: warning: ia64_rse_num_regs' defined but not used
make[2]: *** [libgcc/./unwind-ia64.o] Error 1
make[2]: Leaving directory `/home/jbarnes/working/cross/gcc-build/gcc'
make[1]: *** [libgcc.a] Error 2
make[1]: Leaving directory `/home/jbarnes/working/cross/gcc-build/gcc'
make: *** [all-gcc] Error 2

Jesse Barnes <[email protected]> writes:

|> a) built and installed binutils 2.12 (configured with
|>    --target=ia64-gnu-linux --prefix=/tmp/ia64-cross-3.0)
|> b) tried to build and install gcc 3.0 (configured with the same options
|>    as above), but with 'make LANGUAGES=c' instead of just 'make'

LANGUAGES=c is obsolete, configure with --enable-languages=c instead.

|> Unfortunately, I got hung up in the middle of step (b) with the errors
|> shown below.  IIRC, the Cygnus snapshot tarballs were 'cross-compile
|> ready' in that they had all the necessary header files and utilities
|> needed for a full cross development environment.  Any notes on how
|> those trees were built would be appreciated.

You need to have the target headers installed somewhere and use --with-headers=/place/of/target/headers when configuring the cross compiler.

Andreas.

Andreas Schwab, SuSE Labs, [email protected]
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

I've not been able to build an x86 to ia64 cross compiler using 3.0 "out of the box". I have a patch for 3.0.4 in the tarball at

http://www.ibm.com/developerworks/oss/linux/tools/

which seems to work. It's a hack, so no guarantees.

The 3.1 pre-release branch works fine, so you might consider using CVS or a pre-release snapshot. See http://gcc.gnu.org

The gcc mailing list thread beginning with the following may also be helpful.

http://gcc.gnu.org/ml/gcc/2002-02/msg00585.html

And here's another useful resource, if you haven't already discovered it:

http://www.objsw.com/CrossGCC/

Steve Christiansen <[email protected]>
IBM Linux Technology Center
503-578-4177  IBM T/L: 775-4177
http://www.ibm.com/linux/ltc

I don't recommend using this patch.

Please use instead the prefered solution which I mentioned in this message
http://gcc.gnu.org/ml/gcc/2002-02/msg00643.html

Jim

Yes.

Andreas Schwab mentioned --with-headers=. There is also a --with-libs= option. You need to set up IA-64 .../usr/include and .../use/lib trees on the x86 host, and use these configure options to point at the IA-64 headers and libs respectively.

There is also the matter that gcc 3.0 out of the box does not support cross compiling from a 32-bit host to a 64-bit target. This was fixed for gcc 3.1, but could not be fixed in gcc 3.0 because of latent problems with the powerpc (rs6000) port. I've already pointed at the recommended solution:
http://gcc.gnu.org/ml/gcc/2002-02/msg00643.html

With these two changes, it should work, however, because gcc is big and complicated and there are lots of things that can go wrong in a build. Cross compilers are much harder to get right than native compilers. Personally, I stopped building cross compilers once the ia64-linux systems were stable enough such that I never had to worry about my native builds failing.

If you use the solution suggested by Steve Christiansen, then your cross compiled code will be very different, mainly bigger and slower. If you use the solution I suggested, the code should be the same in theory, but I don't know of anyone who has tried to verify this.

Jim

Excellent.

That more or less did the trick. I did --with-headers=<target_usr_include> and --with-libs=<target_usr_lib>, though the build complained that crt.* and libc.so didn't exist, so I copied from a target machine's /usr/lib directory and created a libc.so -> libc-2.2.4.so symlink. After that was done, gcc-3.0 built and installed as a cross compiler. The target machine I got everything from was a Red Hat 7.1 box with the updated glibc-2.2.4 packages.

However, upon linking the kernel, I got the following errors. Do I need a different version of binutils or something? I'm running 2.12.

/tmp/ia64-cross-3.0/bin/ia64-linux-ld -static -T arch/ia64/vmlinux.lds arch/ia64/kernel/head.o arch/ia64/kernel/init_task.o init/main.o init/version.o --start-group arch/ia64/kernel/kernel.o arch/ia64/mm/mm.o arch/ia64/ia32/ia32.o arch/ia64/sn/kernel/sn.o arch/ia64/sn/io/sgiio.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o kdb/kdb.o drivers/acpi/acpi.o drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/ide/idedriver.o drivers/xscsi/xscsidrv.o drivers/x1394/x1394drv.o drivers/sgi/sn/sn_drivers.a drivers/pci/driver.o drivers/md/mddev.o net/network.o /home/jbarnes/working/snlinux-tot/linux/arch/ia64/lib/lib.a /home/jbarnes/working/snlinux-tot/linux/lib/lib.a /home/jbarnes/working/snlinux-tot/linux/arch/ia64/kdb/kdba.o /home/jbarnes/working/snlinux-tot/linux/arch/ia64/lib/lib.a --end-group -o .tmp_vmlinux1 arch/ia64/kernel/kernel.o(.IA_64.unwind.text.exit+0x0): undefined reference to `local symbols in discarded section .text.exit'
arch/ia64/kernel/kernel.o(.IA_64.unwind.text.exit+0x8): undefined reference to `local symbols in discarded section .text.exit'
arch/ia64/kernel/kernel.o(.IA_64.unwind.text.exit+0x18): undefined reference to `local symbols in discarded section .text.exit'
arch/ia64/kernel/kernel.o(.IA_64.unwind.text.exit+0x20): undefined reference to `local symbols in discarded section .text.exit'
arch/ia64/kernel/kernel.o(.IA_64.unwind.text.exit+0x0): unsupported reloc
arch/ia64/kernel/kernel.o(.IA_64.unwind.text.exit+0x8): unsupported reloc
arch/ia64/kernel/kernel.o(.IA_64.unwind.text.exit+0x18): unsupported reloc
arch/ia64/kernel/kernel.o(.IA_64.unwind.text.exit+0x20): unsupported reloc
make[1]: *** [kallsyms] Error 1
make[1]: Leaving directory `/home/jbarnes/working/snlinux-tot/linux'
make: *** [vmlinux] Error 2

Yeah, that was the easy part to fix...

I prefer cross compiling when possible as it's *much* faster than native compiling.

I'll definitely check this out once I have the cross compiler fully working. Thanks for all your help.

Jesse

Recent binutils complain about dangling references to discarded sections. binutils is up to date, check arch.ia64/vmlinux.lds.S, it should have

  /* Sections to be discarded */
  /DISCARD/ : {
        *(.text.exit)
        *(.data.exit)
        *(.exitcall.exit)
        *(.IA_64.unwind.text.exit)
        *(.IA_64.unwind_info.text.exit)
        }

I had just figured this out... Downgrading to binutils-2.11 also works. Now to see if native builds generate the same code as cross compiles...

Thanks,
Jesse