I am analyzing the following failure and adding my observations here for any help/suggestions.
https://lists.openembedded.org/g/openembedded-core/message/201312. Traceback (most recent call last): File "/home/pokybuild/yocto-worker/genericx86-64/build/meta/lib/oeqa/sdk/cases/rust.py", line 34, in test_cargo_build self._run('cd %s/hello; cargo build' % self.tc.sdk_dir) File "/home/pokybuild/yocto-worker/genericx86-64/build/meta/lib/oeqa/sdk/case.py", line 15, in _run return subprocess.check_output(". %s > /dev/null; %s;" % \ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/subprocess.py", line 466, in check_output return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/subprocess.py", line 571, in run raise CalledProcessError(retcode, process.args, oeqa.utils.subprocesstweak.OETestCalledProcessError: Command '. /home/pokybuild/yocto-worker/genericx86-64/build/build/tmp/work/genericx86_64-poky-linux/core-image-sato/1.0/testimage-sdk/environment-setup-cor e2-64-poky-linux > /dev/null; cd /home/pokybuild/yocto-worker/genericx86-64/build/build/tmp/work/genericx86_64-poky-linux/core-image-sato/1.0/testimage-sdk//hello; cargo build;' returned non-zero exit status 101 Standard Output: warning: `/home/pokybuild/yocto-worker/genericx86-64/build/build/tmp/work/genericx86_64-poky-linux/core-image-sato/1.0/testimage-sdk/sysroots/core2-64-poky-linux/home/cargo/config` is depreca ted in favor of `config.toml` note: if you need to support cargo 1.38 or earlier, you can symlink `config` to `config.toml` Compiling hello v0.1.0 (/home/pokybuild/yocto-worker/genericx86-64/build/build/tmp/work/genericx86_64-poky-linux/core-image-sato/1.0/testimage-sdk/hello) error: rustc interrupted by SIGSEGV, printing backtrace All the failures are similar and fail for rust sdktest with cmd : 'bitbake core-image-sato -c do_testsdk'. It's understood that the "cargo build" cmd fails with a segmentation fault when the cargo binary generated from sdk environment is used. Manually reproducing the issue in verbose mode after invoking the sdk env script: $ /home/pokybuild/build/tmp/work/qemux86_64-poky-linux/core-image-sato/1.0/testimage-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/cargo build -v error: process didn't exit successfully: `rustc -vV` (exit status: 127) --- stderr rustc: symbol lookup error: /home/pokybuild/build/tmp/work/qemux86_64-poky-linux/core-image-sato/1.0/testimage-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/../../lib/libc.so.6: undefined symbol: __tunable_is_initialized, version GLIBC_PRIVATE It seems that the shared objects are unable to find the definition for "__tunable_is_initialized", but it can be found in, build/tmp/work/qemux86_64-poky-linux/core-image-sato/1.0/testimage-sdksysroots/core2-64-poky-linux/usr/src/debug/glibc/2.39+git/elf/dl-tunables.c, as follows: https://github.com/bminor/glibc/blame/431c1be28e443d0d691cec12d634ac60dd6630c8/elf/dl-tunables.c#L153 (Added in glibc 2.39) bool __tunable_is_initialized (tunable_id_t id) { return tunable_list[id].initialized; } I am not sure why the shared objects are unable to find the definition for the given symbol. Also, when compared the readelf dump on rustc binaries for v1.77(where build works) and v1.78, found the following differences in glibc version symbols order. I am not sure if this is causing the issue or not. In rust v1.77, readelf glibc version section: [cid:caf899b7-ba74-4e9d-9250-144a888f98bc] In rust v1.78, readelf glibc version section: [cid:2245b86b-c72a-46ce-8408-50feac5bccb6] Regards, Yash
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#202504): https://lists.openembedded.org/g/openembedded-core/message/202504 Mute This Topic: https://lists.openembedded.org/mt/107543359/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
