History for Cross compilers
changed:
-
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 )
From andre Thu Feb 24 11:08:41 +1300 2005
From: andre
Date: Thu, 24 Feb 2005 11:08:41 +1300
Subject: CMISS_ROOT vs /product/cmiss
Message-ID: <20050224110841+1300@https://www.bioeng.auckland.ac.nz/cms>
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 ??
From karl Wed Jun 29 14:22:40 +1200 2005
From: karl
Date: Wed, 29 Jun 2005 14:22:40 +1200
Subject: libgcc
Message-ID: <20050629142240+1200@https://cms.bioeng.auckland.ac.nz>
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.
From karl Thu Jan 5 16:38:18 +1300 2006
From: karl
Date: Thu, 05 Jan 2006 16:38:18 +1300
Subject: libc ld-linux uil
Message-ID: <20060105163818+1300@www.cmiss.org>
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.
From karl Thu Jan 5 17:28:36 +1300 2006
From: karl
Date: Thu, 05 Jan 2006 17:28:36 +1300
Subject: 64-bit uil
Message-ID: <20060105172836+1300@www.cmiss.org>
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.)
From karl Thu Jan 5 17:57:09 +1300 2006
From: karl
Date: Thu, 05 Jan 2006 17:57:09 +1300
Subject: bash
Message-ID: <20060105175709+1300@www.cmiss.org>
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.
From karl Tue Jan 24 17:14:56 +1300 2006
From: karl
Date: Tue, 24 Jan 2006 17:14:56 +1300
Subject: object compatibility
Message-ID: <20060124171456+1300@www.cmiss.org>
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.
Forgot your password?
New user?