On Wed, 2021-02-24 at 21:16 +0100, Anatol Belski wrote: > On 2/24/2021 5:49 PM, Richard Purdie wrote: > > No, I mean the dynamic loader pointer. > > > > $ tmp/sysroots-uninative/x86_64-linux/usr/bin/patchelf-uninative > > python3-native/python3.9 --print-interpreter > > [...]tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 > > > > Above I'm showing that a native binary in the build (python3-native) > > has the interpreter (dynamic loader) set to our uninative ld.so. > > The SDK is similar. > > > > > As the binary where the issue was sighted has this > > > > > > $ chrpath $(which cargo) > > > /tmp/rust-sdk-deploy-18/sysroots/x86_64-pokysdk-linux/usr/bin/cargo: > > > RUNPATH=$ORIGIN/../lib > > > > > > > > > but then, the DSOs have no rpath set, eg. > > > > > > $ chrpath > > > /tmp/rust-sdk-deploy-18/sysroots/x86_64-pokysdk-linux/usr/bin/../lib/libcrypto.so.1.1 > > > /tmp/rust-sdk-deploy-18/sysroots/x86_64-pokysdk-linux/usr/bin/../lib/libcrypto.so.1.1: > > > no rpath or runpath tag found. > > > > > > > > > so it might lead to the interferrence with the host. Does it perhaps > > > need both $ORIGIN/../../lib and $ORIGIN/../lib if binaries are in /usr ? > > Our dynamic loader knows how to use the specific sysroot and then > > fall back to /usr and /lib. > > Thanks a lot for explaining this. > > Getting back to the initial case led to the question, i'm now able to > check what is the correct dynamic loader: > > $ tmp/sysroots-uninative/x86_64-linux/usr/bin/patchelf-uninative > /tmp/rust-sdk-deploy-18/sysroots/x86_64-pokysdk-linux/usr/bin/cargo > --print-interpreter > /tmp/rust-sdk-deploy-18/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2 > > and also could use --print-needed which would be similar to "readelf -d > ", but it'd be still not possible to check things at the runtime? OFC > knowing what i know now, it's possible to locate the DSO and check > symbols like this: > > $ x86_64-poky-linux-objdump -T > ./sysroots/x86_64-pokysdk-linux/lib/libc.so.6 | grep GLIBC_2.33 > > just seems the catch points are quite subtle :) Perhaps there could be a > recommendation on a good way validating the binaries in the SDK HOST part?
If you what to know what a partiular command is doing for symbols at runtime, you can run it as: LD_DEBUG=all <command> which will have the loader spew out a lot of information about how it is resolving the symbols. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#148572): https://lists.openembedded.org/g/openembedded-core/message/148572 Mute This Topic: https://lists.openembedded.org/mt/80874524/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
