On Tue, Oct 5, 2021 at 1:59 PM Jean-Pierre Doyon <jpdoyon@...> wrote:
I'm attempting to create a USB first boot tarball for our custom iMX6 board that would contain the imx-usb-loader executable, config files and u-boot/SPL files. The goal being to deploy that to the production machine to program the empty boards right after being assembled.
While I had plenty of hurdles figuring out how to do this (I'm still pretty newbie with Yocyo), I managed to get everything just the way I wanted it. But when I get the tarball to the production machine, which runs the exact same Ubuntu 18.04 LTS Linux as the build machine, the imx_usb tool won't run. The reason being that it's missing some library. Running LDD on the executable turns up this:
└─$> ldd usr/bin/imx_usb
linux-vdso.so.1 => (0x00007ffd7031d000)
libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x00007f986a47e000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f986a0b4000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f986a86c000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9869e97000)
/home/jpdoyon/newtrax-layersetup-dunfell/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f986a696000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f9869c8f000)
Why is the ld-linux-x86-64.so.2 using an absolute path while all the other libraries aren't?
If I install the library in the location above, then the executable starts working... So how do I make sure Yocto doesn't do this?
yocto provides a layer to abstract native binaries on top of build
host and thats what you are seeing. Its as designed.