On Thu, 2022-08-25 at 14:03 +0200, Peter Bergin wrote: > Hi Richard, > > On 2022-08-25 10:21, Richard Purdie wrote: > > <snip> > > > I've tried locally to reproduce something. I've built and tested > > > genericx86 and qemuarm64 now on core-image-sato sdk that I saw was the > > > target for the autobuilder. Both tests passes. The failure I see in the > > > autobuilder logs is that the build script can not be executed. On my > > > machine I have that file and it can clearly be executed: > > > > > > $ find > > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/ > > > -name build-script-build > > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build > > > > > > $ > > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build > > > > > > $ file > > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build > > > > > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build: > > > ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically > > > linked, interpreter > > > /storage/yocto/esp5-platform/build/genericx86/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2, > > > BuildID[sha1]=c5d5e70657f8342addf5343d0206c77d9d767fd8, for GNU/Linux > > > 3.2.0, with debug_info, not stripped > > > > > > Found one interesting link here > > > https://github.com/rust-lang/cargo/issues/3553. Unfortunately without > > > answer. But also checked the interpreter in my build which looks correct? > > > > > > $ readelf -a > > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build > > > > grep interpreter > > > [Requesting program interpreter: > > > /storage/yocto/esp5-platform/build/genericx86/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2] > > > > > > > > > So there are some differences between my machine and the autobuilder > > > setup that I can't get. I would need help here as I'm not that familiar > > > with the autobuilder setup. Can it still be some host dependency? I'm > > > running on Ubuntu 22.04. Is it possible to check in a autobuilder setup > > > if the file 'build-script-build' is present and possible to execute? > > After staring at this for an hour, I think the pattern is that is it > > failing on builds with: > > > > SDKMACHINE = "i686" > > > > which probably means the linker isn't linking against the libc and > > loader in the SDK properly. > > > > (i686 SDK binaries should run on x86_64 hosts since we provide our own > > loader and libc) > > Thanks a lot for the reproducer. You are correct, with SDKMACHINE i686 I > was able to reproduce. I want to share some weird stuff and see if > someone can get a clue for a solution. > > Did same analyze on the build-script-build file as I did on a working one:
As I suspected, the dynamic loader on binaries built using the toolchain in the SDK isn't working correctly. "/usr/local/oe-sdk-hardcoded-buildpath/sysroots/i686-pokysdk- linux/lib/ld-linux.so.2" is the value used at build time. This is supposed to be relocated into the SDK's install location at runtime. The question is therefore where is rust getting this value from? You can specify it to the linker at compile time along the lines of: -Wl,--dynamic-linker=/path/to/ld-linux.so.2 or it can be the default that comes from toolchain. It is important it points at the one in the SDK, not on the host system. The bit I don't understand is whether: a) the compiler in the SDK is generating the wrong loader (in which case buildtools-extended-tarball would break which it doesn't) b) rust is hardcoding some dynamic-linker option somewhere it shouldn't c) whether the toolchain is relocating paths correctly or some path isn't relocating and is being used here. I'd suggest first checking that a binary generated by nativesdk-gcc in the SDK has the right loader. If that is the case, see what compiler options are being used to create the build tool and go from there. FWIW you can see/change the interpreter with patchelf. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169878): https://lists.openembedded.org/g/openembedded-core/message/169878 Mute This Topic: https://lists.openembedded.org/mt/93200332/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
