Hi,
I have successfully cross-compiled a program on an x86-64 machine. However, when I try to run on my target machine sh4a, I get the following error:
./ioq3ded.sh4a: /lib/libc.so.6: version `GLIBC_2.11' not found (required by ./ioq3ded.sh4a)

The details of the two machines are as follows:
Compiling machine
architecture: x86-64
LIBC version: 2.11

Executing mechine
architecture: sh4a
LIBC version: 2.5

Programming Language is C

Therefore, as a solution, I tried to compile a 2.11 LIBC library on the sh4a machine. However, it failed because the GCC compiler on the sh4a machine was too old, I don't have the authority, nor is there a possibility for upgrading the GCC.
Furthermore, as an alternative solution, I tried to compile a 2.5 LIBC library on the x86-64 so I can link to them during cross-compilation time. However, the ./configure failed because there were missing required objects.
Moreover, I tried to -static compile the program. However, it failed:
As for ioquake3, I tried to statically build it:
/bin/ld: /r/home7/usr/lib/libc.a(dl-tsd.o): TLS local exec code cannot be linked into shared objects
It seems impossible to statically build it with the old version of gcc we have.
I looked up this problem:
https://bugs.gentoo.org/show_bug.cgi?id=122665

Moreover, I downloaded the LIBC 2.5 for x86-64 from the net:
http://rpm.pbone.net/index.php3/stat...86_64.rpm.html[^]

However, I cannot seem to find the right flags for compiling so that it links against MY specific (2.5 version library) rather than the system ones (2.11 version library).

Here comes my question:
* What should be the "make" flags be? considering that the folder where MY (2.5 version library) is:
./glibc-2_5/lib64/libc.so
And, my make is as follows:
make USE_LOCAL_HEADERS=0 ARCH=sh4a CFLAGS='-fopenmp -Wall -D_GNU_SOURCE=1 -D_REENTRANT' USE_VOIP=0 BUILD_CLIENT=0 BUILD_MISSIONPACK=0

Sorry for my lengthy post. I am still working hard on learning how to build in linux. So, if my question sounds naive, please for give me : )

Best,
Yasir

What you're trying to do is essentially build a cross toolchain. This is never easy. My best suggestion is to be persistent, and recognize that it will take a lot of work and time. There will be loads of dependencies, and a lot of dead-end approaches as you find out what combination of dependencies work together and which do not. Sadly, a cross-native toolchain is possibly the most difficult to build, because so many components' build-tools falsely detect that they are to build for a native architecture.

Having said that, it may work for you to copy the required shared-object libraries from the target host, to the development host. Put them somewhere that is not in conflict with the existing native libraries. Then in your Makefile system, use liberally the '-L' linker option to specify the location of the libraries that belong to the target host. Probably, the path(s) can be added to $(LDFLAGS).

--- rod.

You may not have the authority (i.e. root permission, permission to change something at system level), but you do have a possibility.

One can build 'gcc' (and its dependencies for that matter) running configure with

, so 'gcc' will be installed there.

But, as Rod correctly pointed out, it will be painful. And 'glibc' is not a friendly target to build.