Wrong loader path for HOST and TARGET as same architecture

[otavio]

When building for an x86-64 using an x86-64 host, our binary ends with:

        linux-vdso.so.1 (0x00007ffd4007c000)
        libssl.so.1.1 => /usr/lib/libssl.so.1.1 (0x00007f0146de9000)
        libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1 (0x00007f0146b2c000)
        libdl.so.2 => /lib/libdl.so.2 (0x00007f0146b27000)
        librt.so.1 => /lib/librt.so.1 (0x00007f0146b1c000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00007f0146afc000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f0146ae1000)
        libc.so.6 => /lib/libc.so.6 (0x00007f0146929000)
        libm.so.6 => /lib/libm.so.6 (0x00007f01467e6000)
        .../tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 => /lib/ld-linux-x86-64.so.2 (0x00007f0147338000)

So when running the binary it fails to find the loader and dies badly.

[nastevens]

To double-check - this was resolved by your PR #55 correct?

[otavio]

In fact, no.

It still links wrong. Any idea where to look at?

[nastevens]

My guess is that this is caused by the native wrapper script being used for both native and target compilation. I believe native compilation gets some different options so that it links to Yocto-local copies of libraries.

Do you get the same thing if the linker-wrapper.sh (versus the linker-wrapper-native.sh) script is used for native and target compilation if the host and target are the same? This would sort of be reversing what's being done here. This would potentially mess up native compiling (i.e. build.rs files in dependency crates) but would probably fix the libraries.

If it doesn't work using the target wrapper script his could be a much deeper issue. As far as I know there's not an existing way to specify "use this linker for build scripts" and "use this linker for the final binary" in cargo.

[nicolaiunrein]

Fighting with meta-rust for a while I found your layer and absolutely prefer it over meta-rust. The only problem is that I am running into the same linker issue. I also tried @OtavioS fork but it seems to be the same. Have you found any workarounds yet?

[otavio]

Did this not work for you?

[nicolaiunrein]

I just realized your commit is not in your master branch. Stupid question: how do I get to it?

[allsey87]

@otavio and @nicolaiunrein, could you give a bit more detail on your final work around/solution to this problem?

[nastevens]

For anyone coming to this - see #97. This is currently blocked by changes to the Rust compiler itself.