On 2021-02-24 6:57 p.m., Richard Purdie wrote:
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.
I had other things to do today but for 'fun', in the background, I took:
poky/master + meta-oe/master + meta-rust with Anatol's SDK commits
and bisected poky back to:
7b8df042d0 (HEAD, refs/bisect/bad) glibc: Upgrade to 2.33
(From OE-Core rev: aa87638cf4f2bef66df92f961c7814f6b482fd3d)
This is when I expected problems with the SDK to start but
I thought it was worth confirming mechanically.
Note that the two last bisected commits after the uprev of glibc fail
to even complete the populate_sdk due to the error:
ERROR: core-image-minimal-1.0-r0 do_populate_sdk:
The postinstall intercept hook 'update_gio_module_cache' failed,
Once Richard is happy with the basic meta-rust merge, I can spend more
time and actually look at the linking and debug what's going wrong
if Anatol has not figure it out before that.
../Randy
$ git bisect log
git bisect start
# bad: [1fe4a25f2244fdf67d96109dcb4f49ed75c18b32]
diffoscope: Ensure rpm is configured correctly
git bisect bad 1fe4a25f2244fdf67d96109dcb4f49ed75c18b32
# bad: [1fe4a25f2244fdf67d96109dcb4f49ed75c18b32]
diffoscope: Ensure rpm is configured correctly
git bisect bad 1fe4a25f2244fdf67d96109dcb4f49ed75c18b32
# good: [77d9b5f02aec991540926fe144076e122c17f64d]
pseudo: Update to work with glibc 2.33
git bisect good 77d9b5f02aec991540926fe144076e122c17f64d
# bad: [b6018a1625c22393c1f94e9d23d84f7842b95f24]
acpica: Fix reproducibility issues
git bisect bad b6018a1625c22393c1f94e9d23d84f7842b95f24
# bad: [7283a0b3b6ca49d0d2e13593333a580ef10439a8]
bitbake: bblayers/action: When adding layers,
catch BBHandledException
git bisect bad 7283a0b3b6ca49d0d2e13593333a580ef10439a8
# bad: [c5d80f154de30a6f59f28d4d9d05edcd78469765]
selftest/reproducible: remove spirv-tools-dev from exclusion list
git bisect bad c5d80f154de30a6f59f28d4d9d05edcd78469765
# bad: [adcd9608a725d99e2e6ca74d4a31e6edb353af0c]
bitbake: hashserv: client: Fix handling of null responses
git bisect bad adcd9608a725d99e2e6ca74d4a31e6edb353af0c
# bad: [071f23ad79ac37743d97928f92ded0da61ba9e63]
bash: Disable bracketed input by default
git bisect bad 071f23ad79ac37743d97928f92ded0da61ba9e63
# bad: [8e3b42f44217c9f868d6b8bd52808d357b516a2b]
glibc: Require full ISA support for x86-64 level marker
git bisect bad 8e3b42f44217c9f868d6b8bd52808d357b516a2b
# bad: [51cf44884971d6fc919f2a799fb08ee61acf7518]
glibc: Enable cet
git bisect bad 51cf44884971d6fc919f2a799fb08ee61acf7518
# bad: [7b8df042d0c175388d6230f008b1c83d5c5cd5da]
glibc: Upgrade to 2.33
git bisect bad 7b8df042d0c175388d6230f008b1c83d5c5cd5da
# first bad commit: [7b8df042d0c175388d6230f008b1c83d5c5cd5da] glibc:
Upgrade to 2.33
---
Cheers,
Richard
--
# Randy MacLeod
# Wind River Linux
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#148574):
https://lists.openembedded.org/g/openembedded-core/message/148574
Mute This Topic: https://lists.openembedded.org/mt/80874524/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
