Cross compilers

We have setup cross compiles from Linux for win32 using mingw so that you can build executables that run on windows and for old linux (glibc2.1.3) so that exectuables will run on older machines.

To build an executable using a cross compile you just need to ensure the particular compilers and linkers come first in your path. To make this easy I have set up a couple of scripts.

So for win32 run:

  $(CMISS_ROOT)/bin/i686-linux/i386-mingw32msvc-cross-make instead of make

or:

  $(CMISS_ROOT)/bin/i686-linux/i386-mingw32msvc-cross-configure instead of configure

For glibc2.3 run:

  $(CMISS_ROOT)/bin/i686-linux/i386-glibc23-linux-cross-make instead of make

or:

  $(CMISS_ROOT)/bin/i686-linux/i386-glibc23-linux-cross-configure instead of configure

Executables built using the glibc 2.3 cross compile environment will work on all Linux machines, by default using the system provided run-time libraries. Sometimes, however, it is useful to be able to test the program using the old glibc and associated libraries. To test your glibc executable is built correctly is a little tricky as you probably cannot use the libc from the cross compile as it probably will have version problems with your /lib/ld-linux.so. If you set your LD_LIBRARY_PATH to the cross-compiled lib directory then even /bin/sh and so on probably will have problems. Instead you can run the ld-linux.so directly:

  $(CMISS_ROOT)/cross-compile/i386-glibc23-linux/lib/ld-linux.so.2 --library-path $(CMISS_ROOT)/cross-compile/i386-glibc23-linux/lib   $(CMISS_ROOT)/cm/bin/i686-linux/cm-debug

or to simulate the output of ldd in a csh like shell:

  ( setenv LD_TRACE_LOADED_OBJECTS 1 ; $(CMISS_ROOT)/cross-compile/i386-glibc23-linux/lib/ld-linux.so.2 --library-path $(CMISS_ROOT)/cross-compile/i386-glibc23-linux/lib $(CMISS_ROOT)/cm/bin/i686-linux/cm-debug )

comments:

CMISS_ROOT vs /product/cmiss --andre, Thu, 24 Feb 2005 11:08:41 +1300 reply
As I understand it, the cross compile environments (both glibc 2.1.3 and win32) rely upon CMISS_ROOT being set to /product/cmiss. Perhaps its worth replacing CMISS_ROOT in the above with /product/cmiss ??

libgcc --karl, Wed, 29 Jun 2005 14:22:40 +1200 reply
When linking with g++ or g77 (and possibly sometimes gcc) the GNU compiler uses a shared libgcc (libgcc_s.so). This contains symbols according the the gcc compiler, which can cause problems when running the executable on a platform with an older libgcc_s (from an older gcc) installed.

The option -static-libgcc forces the use of a static libgcc and therefore works around this, but may cause other problems. e.g "when the application wishes to throw and catch exceptions across different shared libraries" See info gcc invoking link for more details.

libc ld-linux uil --karl, Thu, 05 Jan 2006 16:38:18 +1300 reply
The libc from the cross compile requires the ld-linux.so.2 from the cross-compile, but if glibc is used from an executable with a standard .interp section requesting /lib/ld-linux.so.2 then that (most likely incompatibile) file is used instead.

This makes it difficult to set the rpath or LD_LIBRARY_PATH so that the cross-compile files in the bin directory use the libraries from the cross-compile lib directory. Should cross-compile binaries use cross-compile libraries?

Actually the cross-compile gcc needs GLIBC_2.3 so I guess not.

But uil uses libUil.so.3 libMrm.so.3 and libXm.so.3 that are not available in Ubuntu's amd64 ia32-libs package. To cross-compile from a Ubuntu amd64 machine it would be useful to use the cross-compile libraries for uil. So I have moved uil and replaced it with a script to use the cross-compile ld-linux.so.2 to run uil.

64-bit uil --karl, Thu, 05 Jan 2006 17:28:36 +1300 reply
Using a amd64 uil to build for 32-bit gx resulted in errors of the form:

Warning: Urm__WCI_LookupClassDescriptor: Could not find class descriptor for class  Zó - MrmNOT_FOUND

(The version of the Ubuntu amd64 uil was libmotif-dev 2.2.3-1; I don't know the version of the cross-compile motif.)

bash --karl, Thu, 05 Jan 2006 17:57:09 +1300 reply
The bash in the cross-compile bin requires libtermcap.so.2, which is not in either Ubuntu amd64 ia32-libs or cross-compile lib.

There seems no need for a cross-compile bash so I've moved it to bash.hide.

object compatibility --karl, Tue, 24 Jan 2006 17:14:56 +1300 reply
There is no intention that objects compiled against headers from one version of glibc can be linked against a different version of glibc.

However it is useful to use the (cross-compiled) objects from CMISS_ROOT when building local executables (with the local glibc), and in many cases this works.

In glibc 2.3 the implementation of character classification and case conversion functions isalnum, toupper, etc. was changed so as to support uselocale for thread-specific locales.

The old constants __ctype_b __ctype_tolower and __ctype_toupper are still defined in libc.so.6 versioned as GLIBC_2.0. They are available to (the dynamic linker) ld.so as dynamic symbols for executables and shared objects, but are hidden from (the build-time linker) ld.

ld reports "undefined reference" errors when an object built with pre-2.3 glibc headers is linked against a glibc-2.3 libc.so.6.

Linking with -Wl,--warn-unresolved-symbol causes ld to report "undefined reference" errors as warnings instead, and so an executable can be built and the symbols can be found at run time.

However, there is a reason why the symbols are hidden. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=111928#c4 and https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=91290#c6. If an executable uses the uselocale function to set the thread locale, as is done in libstdc++, and then were to use the old implementations of the functions using __ctype_b, etc. they will misbehave.

A sensible solution seems to be to remove the macro implementations of the functions in ctype.h of the cross-compile glibc headers. This could be done by simply defining the preprocessor symbol __NO_CTYPE. Objects compiled against the cross-compile glibc headers would then reference the function implementations (available to ld and versioned as GLIBC_2.0) instead of the macro optimizations. The function implementations would behave correctly when used with uselocale.

An alternative solution is to build a glibc-2.3 (and corresponding gcc) for cross-compiling. Version 2.3 of glibc was available October 2002 and provides macro optimizations for the __ctype_b_loc __ctype_tolower_loc __ctype_toupper_loc functions available to ld and versioned as GLIBC_2.3.