This is the mail archive of the
mailing list for the binutils project.
Cross compiling for Linux on Windows (ld linker output file won't run as executable on linux and has undefined symbols)
- From: Kim <soldoutseashell at gmail dot com>
- To: Binutils Development <binutils at sourceware dot org>
- Date: Mon, 28 Apr 2014 11:47:51 +0800
- Subject: Cross compiling for Linux on Windows (ld linker output file won't run as executable on linux and has undefined symbols)
- Authentication-results: sourceware.org; auth=none
- References: <5357470A dot 2010105 at gmail dot com> <535787B6 dot 4070309 at redhat dot com> <A395A83E-8A07-44C6-A80D-6507B99AC29E at gmail dot com>
I posted a question to stackoverflow about this problem here
and after a few days someone has given me an answer:
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 shard library
linking) isn't found.
That is what happens here. The relevant lines from |readelf -l Test|:
|INTERP0x0000000000000238 0x0000000000400238 0x0000000000400238
0x000000000000002e 0x000000000000002e R1
[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:
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f94ff99f000)
So now I'm wondering how I can fix this on the Windows side. I can make
an attempt at modifying ld to fix the path issue so that the path simply
points back to the original library location on linux but where abouts
in the ld code should I be looking to do this?
Thanks a lot for reading,
On 2014/04/23 17:33, email@example.com wrote:
On Apr 23, 2014, at 2:28 AM, Nicholas Clifton<firstname.lastname@example.org> wrote:
The problem is, the output file is slightly different
than the one produced on linux and it won't run as an executable. I
noticed, for example, that in the version linked on windows there is the
undefined symbol "printf" which appears to have become "puts" instead in
the linux version.
I suspect that the printf/puts variance may be a red herring.
Anyway I'm wondering if anyone knows what is happening here.
bash: ./Test: No such file or dire
What happens if you run "file ./Test" ?
What happens if you run "ldd ./Test" ?
Also make sure the file has its executable bit set. I bet this is the problem.
Also it appears that you are linking against different math's libraries:
Linking on Windows:
attempt to open I:\Linux\libs\lib\x86_64-linux-gnu\libm-2.17.so succeeded
Linking on linux:
attempt to open /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libm.so succeeded
And that as a result you are pulling in the wrong C library:
Linking on Windows:
ld-linux-x86-64.so.2 needed by I:/Linux/libs/lib/x86_64-linux-gnu/libc-2.17.so
Also - which version of the linker are you using ? If it is an old version then that may be causing you problems.