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

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

[Kim]

I'm trying to set up a cross compile for linux ELF files on Windows 
using clang and a version of ld which has been compiled to have elf64 
support. The clang compile part is fine, it outputs ELF obj files that 
work when linked on linux. My test case cpp is just main containing a 
printf statement.

To attempt a link on windows I copied over all of the libraries from my 
ubuntu install and specified the ones that are needed as linker 
arguments in the right order (as they appear on the ld invocation 
performed by g++). 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.

Anyway I'm wondering if anyone knows what is happening here.



Linking on linux:

==================================================
attempt to open 
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crt1.o succeeded
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crt1.o
attempt to open 
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crti.o succeeded
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crti.o
attempt to open /usr/lib/gcc/x86_64-linux-gnu/4.8/crtbegin.o succeeded
/usr/lib/gcc/x86_64-linux-gnu/4.8/crtbegin.o
attempt to open Test.o succeeded
Test.o
attempt to open /usr/lib/gcc/x86_64-linux-gnu/4.8/libstdc++.so succeeded
-lstdc++ (/usr/lib/gcc/x86_64-linux-gnu/4.8/libstdc++.so)
attempt to open /usr/lib/gcc/x86_64-linux-gnu/4.8/libm.so failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/4.8/libm.a failed
attempt to open 
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libm.so 
succeeded
-lm (/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libm.so)
attempt to open /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc_s.so succeeded
-lgcc_s (/usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc_s.so)
attempt to open /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc.so failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc.a succeeded
attempt to open /usr/lib/gcc/x86_64-linux-gnu/4.8/libc.so failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/4.8/libc.a failed
attempt to open 
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libc.so 
succeeded
opened script file 
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libc.so
opened script file 
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libc.so
attempt to open /lib/x86_64-linux-gnu/libc.so.6 succeeded
/lib/x86_64-linux-gnu/libc.so.6
attempt to open /usr/lib/x86_64-linux-gnu/libc_nonshared.a succeeded
(/usr/lib/x86_64-linux-gnu/libc_nonshared.a)elf-init.oS
attempt to open /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 succeeded
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
attempt to open /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc_s.so succeeded
-lgcc_s (/usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc_s.so)
attempt to open /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc.so failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc.a succeeded
attempt to open /usr/lib/gcc/x86_64-linux-gnu/4.8/crtend.o succeeded
/usr/lib/gcc/x86_64-linux-gnu/4.8/crtend.o
attempt to open 
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crtn.o succeeded
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crtn.o
ld-linux-x86-64.so.2 needed by /lib/x86_64-linux-gnu/libc.so.6
found ld-linux-x86-64.so.2 at /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2




nm output on linux:

k@system:/shared$ nm ./Test
0000000000601040 B __bss_start
0000000000601040 b completed.6992
0000000000601030 D __data_start
0000000000601030 W data_start
0000000000400470 t deregister_tm_clones
00000000004004e0 t __do_global_dtors_aux
0000000000600e18 t __do_global_dtors_aux_fini_array_entry
0000000000601038 D __dso_handle
0000000000600e28 d _DYNAMIC
0000000000601040 D _edata
0000000000601048 B _end
00000000004005e4 T _fini
0000000000400500 t frame_dummy
0000000000600e10 t __frame_dummy_init_array_entry
0000000000400718 r __FRAME_END__
0000000000601000 d _GLOBAL_OFFSET_TABLE_
                  w __gmon_start__
00000000004003e0 T _init
0000000000600e18 t __init_array_end
0000000000600e10 t __init_array_start
00000000004005f0 R _IO_stdin_used
                  w _ITM_deregisterTMCloneTable
                  w _ITM_registerTMCloneTable
0000000000600e20 d __JCR_END__
0000000000600e20 d __JCR_LIST__
                  w _Jv_RegisterClasses
00000000004005e0 T __libc_csu_fini
0000000000400550 T __libc_csu_init
                  U __libc_start_main@@GLIBC_2.2.5
000000000040052d T main
                  U puts@@GLIBC_2.2.5
00000000004004a0 t register_tm_clones
0000000000400440 T _start
0000000000601040 D __TMC_END__





Linking on Windows:

==================================================
attempt to open I:\Linux\libs\lib\x86_64-linux-gnu\ld-2.17.so succeeded
I:\Linux\libs\lib\x86_64-linux-gnu\ld-2.17.so
attempt to open I:\Linux\lib\x86_64-linux-gnu\crt1.o succeeded
I:\Linux\lib\x86_64-linux-gnu\crt1.o
attempt to open I:\Linux\lib\x86_64-linux-gnu\crti.o succeeded
I:\Linux\lib\x86_64-linux-gnu\crti.o
attempt to open I:\Linux\gcc\x86_64-linux-gnu\4.8.1\crtbegin.o succeeded
I:\Linux\gcc\x86_64-linux-gnu\4.8.1\crtbegin.o
attempt to open Test.o succeeded
Test.o
attempt to open I:\Linux\lib\x86_64-linux-gnu\libstdc++.so.6.0.18 succeeded
I:\Linux\lib\x86_64-linux-gnu\libstdc++.so.6.0.18
attempt to open I:\Linux\libs\lib\x86_64-linux-gnu\libm-2.17.so succeeded
I:\Linux\libs\lib\x86_64-linux-gnu\libm-2.17.so
attempt to open I:\Linux\gcc\x86_64-linux-gnu\4.8.1\libgcc.a succeeded
attempt to open I:\Linux\lib\x86_64-linux-gnu\libc.so succeeded
opened script file I:\Linux\lib\x86_64-linux-gnu\libc.so
attempt to open /lib/x86_64-linux-gnu/libc.so.6 succeeded
/lib/x86_64-linux-gnu/libc.so.6
attempt to open /usr/lib/x86_64-linux-gnu/libc_nonshared.a succeeded
(I:/Linux/lib/x86_64-linux-gnu/libc_nonshared.a)elf-init.oS
attempt to open /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 succeeded
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
attempt to open I:\Linux\lib\x86_64-linux-gnu\libc_nonshared.a succeeded
attempt to open I:\Linux\gcc\x86_64-linux-gnu\4.8.1\crtend.o succeeded
I:\Linux\gcc\x86_64-linux-gnu\4.8.1\crtend.o
attempt to open I:\Linux\lib\x86_64-linux-gnu\crtn.o succeeded
I:\Linux\lib\x86_64-linux-gnu\crtn.o
ld-linux-x86-64.so.2 needed by 
I:/Linux/libs/lib/x86_64-linux-gnu/libc-2.17.so
found ld-2.17.so at I:\Linux\libs\lib\x86_64-linux-gnu\ld-2.17.so




nm output of windows generated executable file

k@system:/shared$ nm ./Test
0000000000601040 B __bss_start
0000000000601040 b completed.6992
0000000000601030 D __data_start
0000000000601030 W data_start
0000000000400470 t deregister_tm_clones
00000000004004e0 t __do_global_dtors_aux
0000000000600e18 t __do_global_dtors_aux_fini_array_entry
0000000000601038 D __dso_handle
0000000000600e28 d _DYNAMIC
0000000000601040 D _edata
0000000000601048 B _end
00000000004005f4 T _fini
0000000000400500 t frame_dummy
0000000000600e10 t __frame_dummy_init_array_entry
0000000000400728 r __FRAME_END__
0000000000601000 d _GLOBAL_OFFSET_TABLE_
                  w __gmon_start__
00000000004003d8 T _init
0000000000600e18 t __init_array_end
0000000000600e10 t __init_array_start
0000000000400600 R _IO_stdin_used
                  w _ITM_deregisterTMCloneTable
                  w _ITM_registerTMCloneTable
0000000000600e20 d __JCR_END__
0000000000600e20 d __JCR_LIST__
                  w _Jv_RegisterClasses
00000000004005f0 T __libc_csu_fini
0000000000400560 T __libc_csu_init
                  U __libc_start_main@@GLIBC_2.2.5
0000000000400530 T main
                  U printf@@GLIBC_2.2.5
00000000004004a0 t register_tm_clones
0000000000400440 T _start
0000000000601040 D __TMC_END__
k@system:/shared$ ./Test
bash: ./Test: No such file or dire

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

[Nicholas Clifton]

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

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

[pinskia]

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

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

-dynamic-linker wrong location (why does it add mingw to the path string?)

[Kim]

-dynamic-linker /lib64/ld-linux-x86-64.so.2

For some reason this makes the interpreter location
I:/MingW/msys/1.0/lib64/ld-linux-x86-64.so.2
in the executable

kim@Backup ~/shared $ ldd -d ./Test
	linux-vdso.so.1 =>  (0x00007fff2e5fe000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f859965e000)
	I:/MingW/msys/1.0/lib64/ld-linux-x86-64.so.2 => 
/lib64/ld-linux-x86-64.so.2 (0x00007f8599a41000)

Re: -dynamic-linker wrong location (why does it add mingw to the path string?)

[LRN]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01.05.2014 16:46, Kim wrote:
> -dynamic-linker /lib64/ld-linux-x86-64.so.2
> 
> For some reason this makes the interpreter location 
> I:/MingW/msys/1.0/lib64/ld-linux-x86-64.so.2 in the executable
> 
> kim@Backup ~/shared $ ldd -d ./Test linux-vdso.so.1 =>
> (0x00007fff2e5fe000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
> (0x00007f859965e000) I:/MingW/msys/1.0/lib64/ld-linux-x86-64.so.2 => 
> /lib64/ld-linux-x86-64.so.2 (0x00007f8599a41000)
> 
> 

Are you using MSYS?

- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)

iQEcBAEBAgAGBQJTYm3FAAoJEOs4Jb6SI2CwAv8IAN2MADymEme9yMsW8ag1omiz
MLsY/zq81kn0ZVvs5MgfKcjwDlgIdDBkpNQA3O1jGXHZRi2Jx/j9QDB1VXVwoEZu
TuDv9q2Xu1Xmx045a9bfvGv5VuM7Hc/qkRMUuD73qP09FYENzECOtgprUN+BOR5Y
gOyS80y8oCP977vHTwAfk5JSnj8m7yyuWkHgMQhMPM3IMd4lwDF80/Lw55FOrz1V
rwh1KLg56QnPqNgQluRumXaduZVZ54gqADHXtzXGh2eDGQ3fC3L5Qfv4x0foohd1
WNsDa4dwp6m0re+XcVfzeUXlY19qX7CAsrAD5LB70nHAj8JM0Rx2OxYEAcisHFQ=
=ECyv
-----END PGP SIGNATURE-----