Re: Cross-compiling is broken. Help me fix it.

[Benjamin Kosnik <bkoz at cygnus dot com>]

> I'm attempting to cross-compile this library (host i686-pc-linux-gnu,
> target i386-lynx-lynxos).  I've run into several problems.

Yeah. This is a weak area, but needs to be fixed sooner rather than later,
so it might as well get cleaned up.

I have not tried to cross compile the library. I suppose it would be
simplest for newlib-related targets like strongarm2-elf, for instance.
Then we could just add config/newlib/* stuff. Hmmm. . .

> The first thing I did was to set some environment variables so that the
> correct compilers would be used.  In particular I did the following:
> 
>     setenv AR     i386-lynx-lynxos-ar
>     setenv AS     i386-lynx-lynxos-as
>     setenv CC     i386-lynx-lynxos-gcc
>     setenv CXX    i386-lynx-lynxos-g++
>     setenv LD     i386-lynx-lynxos-ld
>     setenv NM     i386-lynx-lynxos-nm
>     setenv RANLIB i386-lynx-lynxos-ranlib

seems wrong. You might want to take a look at libjava or zlib for the java
runtime. (look for aclocal.m4 macros to get started)

>     ../libstdc++-2.90.7/configure
>     --prefix=/usr/local/libstdc++/2.90.7/i386-lynx-lynxos
>     --with-gnu-ld
>     --host=i686-pc-linux-gnu
>     --target=i386-lynx-lynxos

quite ambitious. Don't you need to specify a path to lynxos headers?

>     checking whether byte ordering is bigendian... configure: error: can
>     not run test program while cross compiling
> 
> Ok, so I go in and hack that part of the configure script to simply assume
> little endian instead of quitting with that error message.  Configuration
> now finishes.  But during the make, I run into the following problem:

No. There has to be a better way. This is curently being warned about by
autoconf anyway, so should change.

>     make[2]: Entering directory `/home2/bgarcia/dload/libstdc++/lynx/src'
>     /bin/sh ../../libstdc++-2.90.7.new/mknumeric_limits `pwd`/.. ../../libstdc++-2.90.7.new
>     running mknumeric_limits
>     /tmp/ccql0Mmf.o(.text+0xbc3):gen-num-limits.cc: undefined reference to
>     `value<bool>::epsilon'
>     (...(and about 20 more similar error messages)...
> 
> So I take a look at mknumeric_limits.
> It appears to be attempting to create a file called gen-num-limits.cc,
> compile it into a program called gen-num-limits, and then run that
> program to produce std_limits.h.  There's at least one problem with that:
> 
> 1) It's attempting to use CXX (in my case i386-lynx-lynxos-g++) to compile
>    the program.  Using a cross-compiler does not seem like the right thing
>    to do here.
> 
> Ok, so I hack mknumeric_limits and change all occurrences of CXX to
> HOST_CXX, which defaults to g++.  Now I try to build again and get the
> following:
> 
>     i386-lynx-lynxos-g++ -DHAVE_CONFIG_H -I. -I../../libstdc++-2.90.7.new/src -I.. -nostdinc++ -I../../libstdc++-2.90.7.new/config/default -I../../libstdc++-2.90.7.new -I../../libstdc++-2.90.7.new/stl -I../../libstdc++-2.90.7.new/libio -D_GNU_SOURCE -fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings -Winline -Werror -g -fno-honor-std -c ../src/limitsMEMBERS.cc -o limitsMEMBERS.o
>     In file included from ../src/limitsMEMBERS.cc:37:
>     ../bits/std_limits.h: In function `static long double numeric_limits<long double>::min()':
>     ../bits/std_limits.h:690: no field `__convert_long_double_i' in union being initialized
>     ../bits/std_limits.h:690: confused by earlier errors, bailing out
>     make[2]: *** [../src/limitsMEMBERS.lo] Error 1
> 
> So now it appears that std_limits.h is relying on my host-machine's header
> files (float.h, which has __convert_long_double_i defined).  I'm not sure
> how to work around this problem.


... you would need the lynxos headers, which you'll need anyway for stuff
like ctype to work.

More importantly, mknumeric_limits does a pretty complete job of probing
the (host?) floating point environment as part of it's creation of
<limits>. I don't think this will work for things that are cross compiles
(because a) sim might not be built and b) sim probably can't handle the
fp-env probe (?? has anybody tried it? Gaby how likely is this to work?)

So really, the probable solution is to pre-generate a default "32bit"
<limits> file and use that for cross-compiles. . . . weak, but I don't see
any other way.

-benjamin