* Current native SDK glibc compat @ 2021-02-24 11:40 Anatol Belski 2021-02-24 12:32 ` [OE-core] " Richard Purdie 0 siblings, 1 reply; 8+ messages in thread From: Anatol Belski @ 2021-02-24 11:40 UTC (permalink / raw) To: openembedded-core; +Cc: randy.macleod Hi, the current master build seems to be broken with symbols unavailable from the host glibc. The following is to see on the SDK built and installed on the same host Ubuntu 18.04.5 having glibc 2.27: $ . /tmp/poky-sdk-master-00/environment-setup-core2-64-poky-linux $ ldd $(which $CC) /tmp/poky-sdk-master-00/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/x86_64-poky-linux-gcc: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/poky-sdk-master-00/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/x86_64-poky-linux-gcc) linux-vdso.so.1 (0x00007ffdaaca2000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007feab87eb000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007feab83fa000) /tmp/poky-sdk-master-00/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007feab8b89000) $ objdump -T $(which $CC) | grep GLIBC_2.33 objdump: warning: /tmp/poky-sdk-master-00/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/x86_64-poky-linux-gcc: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0008002 objdump: warning: /tmp/poky-sdk-master-00/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/x86_64-poky-linux-gcc: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001 objdump: warning: /tmp/poky-sdk-master-00/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/x86_64-poky-linux-gcc: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.33 lstat 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.33 stat 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.33 fstat Similar issue is observer on several other binaries consuming same symbols. This doesn't seem a uninative issue, avoiding uninative doesn't change this. Stable branches are fine. I was looking through the doc but couldn't find a way to enforce a certain symbol version usage. Please advise on a proper way to fix this. Regards Anatol ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [OE-core] Current native SDK glibc compat 2021-02-24 11:40 Current native SDK glibc compat Anatol Belski @ 2021-02-24 12:32 ` Richard Purdie 2021-02-24 12:56 ` Anatol Belski 0 siblings, 1 reply; 8+ messages in thread From: Richard Purdie @ 2021-02-24 12:32 UTC (permalink / raw) To: Anatol Belski, openembedded-core; +Cc: randy.macleod Hi, On Wed, 2021-02-24 at 12:40 +0100, Anatol Belski wrote: > the current master build seems to be broken with symbols unavailable > from the host glibc. The following is to see on the SDK built and > installed on the same host Ubuntu 18.04.5 having glibc 2.27: > > $ . /tmp/poky-sdk-master-00/environment-setup-core2-64-poky-linux > > $ ldd $(which $CC) > /tmp/poky-sdk-master-00/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/x86_64-poky-linux-gcc: > /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found We change the loader path inside our SDK binaries so you can't trust the output from ldd, it will find a different result to what you'd see when you run the binary. What issue are you seeing trying to run these? Cheers, Richard ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [OE-core] Current native SDK glibc compat 2021-02-24 12:32 ` [OE-core] " Richard Purdie @ 2021-02-24 12:56 ` Anatol Belski 2021-02-24 16:49 ` Richard Purdie 0 siblings, 1 reply; 8+ messages in thread From: Anatol Belski @ 2021-02-24 12:56 UTC (permalink / raw) To: Richard Purdie, openembedded-core; +Cc: randy.macleod On 2/24/2021 1:32 PM, Richard Purdie wrote: > Hi, > > On Wed, 2021-02-24 at 12:40 +0100, Anatol Belski wrote: >> the current master build seems to be broken with symbols unavailable >> from the host glibc. The following is to see on the SDK built and >> installed on the same host Ubuntu 18.04.5 having glibc 2.27: >> >> $ . /tmp/poky-sdk-master-00/environment-setup-core2-64-poky-linux >> >> $ ldd $(which $CC) >> /tmp/poky-sdk-master-00/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/x86_64-poky-linux-gcc: >> /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found > We change the loader path inside our SDK binaries so you can't trust the > output from ldd, it will find a different result to what you'd see > when you run the binary. > > What issue are you seeing trying to run these? Initially it was sighted here appearing when a binary is actually invoked: https://github.com/meta-rust/meta-rust/pull/313#issuecomment-782784056 I went digging to see similar cases. Regarding the loader path, are you referring to this? $ chrpath $(which $CC) /tmp/poky-sdk-master-00/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/x86_64-poky-linux-gcc: RPATH=$ORIGIN/../../lib 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 ? Thanks Anatol ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [OE-core] Current native SDK glibc compat 2021-02-24 12:56 ` Anatol Belski @ 2021-02-24 16:49 ` Richard Purdie 2021-02-24 20:16 ` Anatol Belski 0 siblings, 1 reply; 8+ messages in thread From: Richard Purdie @ 2021-02-24 16:49 UTC (permalink / raw) To: Anatol Belski, openembedded-core; +Cc: randy.macleod On Wed, 2021-02-24 at 13:56 +0100, Anatol Belski wrote: > On 2/24/2021 1:32 PM, Richard Purdie wrote: > > Hi, > > > > On Wed, 2021-02-24 at 12:40 +0100, Anatol Belski wrote: > > > the current master build seems to be broken with symbols unavailable > > > from the host glibc. The following is to see on the SDK built and > > > installed on the same host Ubuntu 18.04.5 having glibc 2.27: > > > > > > $ . /tmp/poky-sdk-master-00/environment-setup-core2-64-poky-linux > > > > > > $ ldd $(which $CC) > > > /tmp/poky-sdk-master-00/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/x86_64-poky-linux-gcc: > > > /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found > > We change the loader path inside our SDK binaries so you can't trust the > > output from ldd, it will find a different result to what you'd see > > when you run the binary. > > > > What issue are you seeing trying to run these? > > Initially it was sighted here appearing when a binary is actually invoked: > > https://github.com/meta-rust/meta-rust/pull/313#issuecomment-782784056 > > I went digging to see similar cases. > > > Regarding the loader path, are you referring to this? > > $ chrpath $(which $CC) > /tmp/poky-sdk-master-00/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/x86_64-poky-linux-gcc: > RPATH=$ORIGIN/../../lib 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. Cheers, Richard ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [OE-core] Current native SDK glibc compat 2021-02-24 16:49 ` Richard Purdie @ 2021-02-24 20:16 ` Anatol Belski 2021-02-24 23:57 ` Richard Purdie 0 siblings, 1 reply; 8+ messages in thread From: Anatol Belski @ 2021-02-24 20:16 UTC (permalink / raw) To: Richard Purdie, openembedded-core; +Cc: randy.macleod On 2/24/2021 5:49 PM, Richard Purdie wrote: > On Wed, 2021-02-24 at 13:56 +0100, Anatol Belski wrote: >> On 2/24/2021 1:32 PM, Richard Purdie wrote: >>> Hi, >>> >>> On Wed, 2021-02-24 at 12:40 +0100, Anatol Belski wrote: >>>> the current master build seems to be broken with symbols unavailable >>>> from the host glibc. The following is to see on the SDK built and >>>> installed on the same host Ubuntu 18.04.5 having glibc 2.27: >>>> >>>> $ . /tmp/poky-sdk-master-00/environment-setup-core2-64-poky-linux >>>> >>>> $ ldd $(which $CC) >>>> /tmp/poky-sdk-master-00/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/x86_64-poky-linux-gcc: >>>> /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found >>> We change the loader path inside our SDK binaries so you can't trust the >>> output from ldd, it will find a different result to what you'd see >>> when you run the binary. >>> >>> What issue are you seeing trying to run these? >> Initially it was sighted here appearing when a binary is actually invoked: >> >> https://github.com/meta-rust/meta-rust/pull/313#issuecomment-782784056 >> >> I went digging to see similar cases. >> >> >> Regarding the loader path, are you referring to this? >> >> $ chrpath $(which $CC) >> /tmp/poky-sdk-master-00/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/x86_64-poky-linux-gcc: >> RPATH=$ORIGIN/../../lib > 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? Thanks Anatol ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [OE-core] Current native SDK glibc compat 2021-02-24 20:16 ` Anatol Belski @ 2021-02-24 23:57 ` Richard Purdie 2021-02-25 0:23 ` Randy MacLeod 0 siblings, 1 reply; 8+ messages in thread From: Richard Purdie @ 2021-02-24 23:57 UTC (permalink / raw) To: Anatol Belski, openembedded-core; +Cc: randy.macleod 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [OE-core] Current native SDK glibc compat 2021-02-24 23:57 ` Richard Purdie @ 2021-02-25 0:23 ` Randy MacLeod 2021-02-25 19:22 ` Anatol Belski 0 siblings, 1 reply; 8+ messages in thread From: Randy MacLeod @ 2021-02-25 0:23 UTC (permalink / raw) To: Richard Purdie, Anatol Belski, openembedded-core 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [OE-core] Current native SDK glibc compat 2021-02-25 0:23 ` Randy MacLeod @ 2021-02-25 19:22 ` Anatol Belski 0 siblings, 0 replies; 8+ messages in thread From: Anatol Belski @ 2021-02-25 19:22 UTC (permalink / raw) To: Randy MacLeod, Richard Purdie, openembedded-core [-- Attachment #1: Type: text/plain, Size: 7107 bytes --] Hi, On 2/25/2021 1:23 AM, Randy MacLeod wrote: > 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. Thanks for this hint. Applied to the current dev artifacts i can now see what is loaded: $ LD_DEBUG=all cargo 2>&1 | grep GLIBC_2.33 29463: checking for version `GLIBC_2.33' in file /tmp/rust-sdk-deploy-18/sysroots/x86_64-pokysdk-linux/lib/libc.so.6 [0] required by file /tmp/rust-sdk-deploy-18/sysroots/x86_64-pokysdk-linux/usr/bin/../lib/libcrypto.so.1.1 [0] 29463: checking for version `GLIBC_2.33' in file /tmp/rust-sdk-deploy-18/sysroots/x86_64-pokysdk-linux/lib/libc.so.6 [0] required by file /tmp/rust-sdk-deploy-18/sysroots/x86_64-pokysdk-linux/usr/bin/../lib/libcurl.so.4 [0] > > 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, I recall failures in post install scripts failing due to missing files, where scripts under scripts/postinst-intercepts/ sometimes make wrong assumptions. Unfortunately we never caught the causes. Anyway, this one doesn't look related to glibc whatsoever. > 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. > Yeah, i'll continue working on Rust SDK integration and in particular checking through teh current patch. On the particular glbic issue - while I built using master to pursue a reproduce, I also used ldd for the checks. However, as we've just learned ldd would be the wrong way - other than that, the binaries wasn't showing the warnings about missing symbols at runtime. I'm also more focused on the Rust itself, but anyway will keep eyes open to this. Regards Anatol > ../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 >> > > > > > [-- Attachment #2: Type: text/html, Size: 10872 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-02-25 19:22 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-02-24 11:40 Current native SDK glibc compat Anatol Belski 2021-02-24 12:32 ` [OE-core] " Richard Purdie 2021-02-24 12:56 ` Anatol Belski 2021-02-24 16:49 ` Richard Purdie 2021-02-24 20:16 ` Anatol Belski 2021-02-24 23:57 ` Richard Purdie 2021-02-25 0:23 ` Randy MacLeod 2021-02-25 19:22 ` Anatol Belski
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.