Cross Compiler Ldd

cross compiler ldd

This is a bit of a kluge, but it's the best solution I could find, and it really works quite well for basic use - just save this script as "arm-none-linux-gnueabi-ldd" with your other cross tools.

#!/bin/sh
arm-none-linux-gnueabi-readelf -a $1 | grep "Shared library:"

Cross compiling for Linux on Windows (linker output file won't run as executable on linux and has undefined symbols)

The "No such file or directory" error can be a bit confusing if the file is there and executable. You will also get that error on executing a file if the ELF interpreter (the program that performs the shared library linking) isn't found.

That is what happens here. The relevant lines from readelf -l Test:

INTERP         0x0000000000000238 0x0000000000400238 0x0000000000400238
               0x000000000000002e 0x000000000000002e  R      1
    [Requesting program interpreter: I:\Linux\libs\lib\x86_64-linux-gnu\ld-2.17.so]

Obviously that interpreter will not be found on a Linux system. For some reason ldd shows a file mapping to the correct interpreter for that entry.

I can't tell you how to fix that in your Windows build environment, but with a correct interpreter ldd won't show a mapping. For example:

$ ldd /bin/true
    linux-vdso.so.1 (0x00007fff1bbff000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f94ff99f000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f94ffd73000)

Cross-compiler library communication

You might find this article interesting Binary-compatible C++ Interfaces. The lesson in general is, never pass STL container, boost or anything of the like. Like the two other answers your best bet is to stick with PODs and functions with a calling convention specified.

Since implementations of the STL vary from compiler to compiler, it is not safe to pass STL classes. You can then either require the user to a specific implementation of the STL (and probably a specific version as well), or simply not use the STL between libraries.

Further more stick with the calling conventions where the behaviour can be considered cross compiler frieindly. For instance __cdecl and __stdcall will be handled equally on most compilers, while the __fastcall calling convention will be a problem, especially if you wish to use the code in C++ Builder.

As the article "Binary-compatible C++ Interface" mentions you can use interface as well, as long as you remember a few basic principles.

1. Always make interfaces pure virtual classes (that is no implementations).
2. Make sure to use a proper calling convention for the member functions in the interface (the article mentions __stdcall for Windows.
3. Keep the memory clean up at the same side of the DLL boundary.
4. And quite a few other things, like don't use exceptions, don't overload functions in the interface (compilers treat this differently), etc. Find them all at the bottom of the article.

You might want to read more about the Component Object Model (COM) if you choose to go with the C++ interfaces, to get an idea about how and why this will be able to work across compilers.

---

Related Topics