1. Home
  2. Embedded Linux
  3. libc-2.3.3 and gcc-3.4.3 cross compiler

libc-2.3.3 and gcc-3.4.3 cross compiler

We are running embedded linux-2.4.21 on an ARM9 processor (Cirrus Logic with MaverickCrunch math coprocessor) and I have successfully cross-compiled a gnu toolchain on Windows (cygwin), Linux, and Solaris 2.8 (sparc). I am able to cross-build binaries on all platforms and run them on the ARM9 so it looks as if everything is running fine.

My question is that the (glibc) libc-2.3.3.so that was built on Windows and Solaris is a different size from the one built on Linux and the one that is actually residing on the ARM9 board. I listed the maps (arm-linux-nm and sort) and notice that the function offsets are slightly different. For example:

Window and Solaris libc-2.3.3.so:

0002e360 T atof 0002e37c T atoi 0002e39c T atol 0002e3bc T atoll

ARM9 libc-2.3.3.so:

0002e2e0 T atof 0002e2fc T atoi 0002e31c T atol 0002e33c T atoll

Will this cause problems or not? So far my programs seem to run fine but I am a little concerned by this. Should I be using exactly the same libc in the cross-compile environement as the running environment?

Thanks,

Snake

Reply to
Ultra5
Loading thread data ...

To answer my own question, (from:

formatting link

The magic trick here that makes it work is a chunk of data called a Procedure Linkage Table (PLT), a table in the program that lists every function that a program calls. When the program is started, the PLT contains code for each function to query the runtime linker for the address at which it has loaded a function. It then fills in that entry in the table and jumps there. As each function is called, its entry in the PLT is simplified into a direct jump to the loaded function.

Reply to
Ultra5

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.