building cross compiler for ia64 on i386 system

Kai Ruottu
Tue Oct 30 15:28:00 GMT 2001

"MEHTA,HIREN (A-SanJose,ex1)" wrote:
> Hi List,
> I am trying to build a cross compiler for ia64 system on i386 system.
> I am following the same order for building the cross compiler as mentioned
> in the FAQ at : First I built the binutils
> without any problems. Then I started building gcc. I get the following
> error :
> -c ../../gcc-3.0.2/gcc/config/ia64/fde-glibc.c -o libgcc/./fde-glibc.o
> ../../gcc-3.0.2/gcc/config/ia64/fde-glibc.c:42:3: #error You need GLIBC
> 2.2.4 or later on IA-64 Linux
> I tried doing cross-compilation of glibc but that needs to the cross
> compiler which I am trying to build.
> How do I fix this problem ? Any help is greatly appreciated.

 The 'gcc/Makefile' has a line or more like:

	LIBGCC = libgcc.a  (or

and this requests it being built... So the solution is to leave this undone,
temporalily, and edit these lines to be replaced with:

	# LIBGCC = libgcc.a  (or

Also the 'LIBGCC1_TEST = libgcc1-test' (or what it was) for testing must be
edited to be empty...

 And then continue with the 'make all-gcc' to produce only GCC, now without
producing the 'libgcc.a' and 'libgcc1-test'... And then install GCC with
the 'make install-gcc', build glibc-2.2.4 and install it... And then try the
'libgcc.a', '' etc. again, first taking back all those fixes to
the 'gcc/Makefile'... Simple as a pie, but perhaps not so easy to find out
without first knowing what the 'libgcc.a' is (only a library...).

 "If you cannot build something still unnecessary, don't try to build it",
could be a golden rule in all these vain tries to build 'libiberty' etc.
before the C-library (newlib or glibc) is ready... Now this could be extended
to the 'libgcc.a' and '' case with the 'gcc-3.0.x'...

 Perhaps there is a new '--disable-libgcc' option for configure already, but
fixing the Makefile is the old workaround for these 'libgcc-unneeded'-cases.

 Or perhaps just creating some dummy and empty ones:

	$ >libgcc.a
	$ >

or doing the same with 'touch', is enough... 'make' sees them already done,
and is happy... Perhaps a 'touch libgcc2.ready' will also be needed... This
a 'stamp'-file, like the 'stmp-multilib' for the targets with multilibs
(versions for different CPUs and hard/soft-float settings)...

 These were the good news, but the bad news are that there can be problems
in cross-compiling glibc-2.2.4 for 'ia64-linux'... And of course it is still
unclear whether gcc-3.0.2 is suitable for glibc-compile at all... The
'--disable-sanity-checks' must be used before the glibc-2.2.4-configure
accepts the gcc-3.0.2... But some 'suitable' compiler must exist (gcc-2.96
in RedHat 7.2 distribution?)...

 Perhaps a little lazyness could be suggested: The "Install the target libs
and headers, then build GCC"-method, ie. copying the ia64-libs and headers
from the RedHat 7.2 or from some other 'ia64-linux' distribution, then using
it while building GCC, then perhaps updating glibc (if it succeeds on a 32-
bit cross-environment...), is always the easy case... At least this enables
some us (like me) to continue in our lazyness and to not write long explanations
about the possible workarounds in reinventing the wheel (ie. how to produce GCC
without a glibc, when getting the prebuilt glibc should succeed quite easily ;-)

 Sorry, I am a little tired to all these 'I want to reinvent the wheel'-questions
when writing about the Linux-targets, which shouldn't be hard at all in the
libs and headers-issue, meanwhile it is very hard to find any libs and headers
for targets like the Apple's 'OS X', SGI's Irix 6.x, HP's UX, IBM's AIX etc.,
without first purchasing the target system... So what could be the reason for
not just downloading a glibc from a 'ia64-linux' distribution, or copying the
needed target stuff from the target system, if it is available somewhere?

 BTW, has the FreeBSD-issue bettered at all, must a Linux-owner still download
a 30+ Megabyte "FreeBSD Basic Install"-kit, in order to get the libs and headers
for it?  Anyone tried a Linux-x-FreeBSD cross-toolkit lately? I did this a couple
of years ago with FreeBSD 3.0 or something, and then the FreeBSD target libs and
headers weren't separately packaged, a'la libc-binaries for Linux... But OpenBSD
and NetBSD were more 'open' and Linux-like in this issue...

Cheers, Kai

Want more information?  See the CrossGCC FAQ,
Want to unsubscribe? Send a note to

More information about the crossgcc mailing list