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

[Kim]

Hey guys,

I posted a question to stackoverflow about this problem here 
(http://stackoverflow.com/questions/23234795/cross-compiling-for-linux-on-windows-linker-output-file-wont-run-as-executable/23329940?noredirect=1#23329940) 
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:

|$ 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)|



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,
Kim

On 2014/04/23 17:33, pinskia@gmail.com wrote:
>> On Apr 23, 2014, at 2:28 AM, Nicholas Clifton<nickc@redhat.com>  wrote:
>>
>> Hi Kim,
>>
>>> 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.
>>> k@system:/shared$ ./Test
>>> 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.
>
> Thanks,
> Andrew
>
>> 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.
>>
>> Cheers
>>   Nick
>>