| Summary: | Check libraries linked with qemu | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Alexandre Belloni <alexandre.belloni> |
| Component: | devtools / tool chain | Assignee: | New Comer Bugs <newcomer> |
| Status: | NEW --- | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | Medium+ | CC: | adrian.freihofer, meta.mr.watcher, meta.watcher, randy.macleod, richard.purdie, ross.burton, tgamblin |
| Version: | unspecified | ||
| Target Milestone: | 6.99 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | NEWCOMER | ||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
|
Description
Alexandre Belloni
2022-12-12 17:41:56 UTC
I've a series that I need to actually submit that turns all of the 'auto' dependencies to forcibly on, which will stop these automatic dependencies happening. Bulk move to 4.3 M3. Moved to 5.0 M1 since it's an enhancement. Move to 5.99 since no one is actively working on this issue. Probably I just run into this issue. Here are the details:
- The host is a (not yet supported) Fedora 42
- A build folder where qemu-native is built without sstate-cache (bitbake core-image-full-cmdline).
- Run oe-selftest in build-st: Some tests such as c_cpp.CMakeTests which use qemu usermode failed.
The root cause seems to be that the qemu-x86_64 just segfaults.
From a clean shell, without oe-init-build-env sourced: qemu-x86_64 -h works:
~/projets/oss/poky/build/tmp/work/core2-64-poky-linux/meson-example/1.0/recipe-sysroot-native/usr/bin/qemu-x86_64 -h
usage: qemu-x86_64 [options] program [arguments...]
Linux CPU emulator (compiled for x86_64 emulation)
...
ldd ~/projets/oss/poky/build/tmp/work/core2-64-poky-linux/meson-example/1.0/recipe-sysroot-native/usr/bin/qemu-x86_64
linux-vdso.so.1 (0x00007fc199645000)
libm.so.6 => /lib64/libm.so.6 (0x00007fc199532000)
libglib-2.0.so.0 => /home/adrian/projets/oss/poky/build/tmp/work/core2-64-poky-linux/meson-example/1.0/recipe-sysroot-native/usr/bin/../lib/libglib-2.0.so.0 (0x00007fc1990b2000)
libgmodule-2.0.so.0 => /home/adrian/projets/oss/poky/build/tmp/work/core2-64-poky-linux/meson-example/1.0/recipe-sysroot-native/usr/bin/../lib/libgmodule-2.0.so.0 (0x00007fc19952c000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc198ec0000)
/home/adrian/projets/oss/poky/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fc199647000)
libpcre2-8.so.0 => /home/adrian/projets/oss/poky/build/tmp/work/core2-64-poky-linux/meson-example/1.0/recipe-sysroot-native/usr/bin/../lib/./libpcre2-8.so.0 (0x00007fc1994bf000)
However, from build-st qemu-x86_64 -h segfaults:
~/projets/oss/poky/build-st/tmp/work/core2-64-poky-linux/meson-example/1.0/recipe-sysroot-native/usr/bin/qemu-x86_64 -h
Segmentation fault (core dumped)
ldd ~/projets/oss/poky/build-st/tmp/work/core2-64-poky-linux/meson-example/1.0/recipe-sysroot-native/usr/bin/qemu-x86_64
linux-vdso.so.1 (0x00007fee8cdcb000)
libm.so.6 => /lib64/libm.so.6 (0x00007fee8ccb8000)
libglib-2.0.so.0 => /home/adrian/projets/oss/poky/build-st/tmp/work/core2-64-poky-linux/meson-example/1.0/recipe-sysroot-native/usr/bin/../lib/libglib-2.0.so.0 (0x00007fee8c8b2000)
libgmodule-2.0.so.0 => /home/adrian/projets/oss/poky/build-st/tmp/work/core2-64-poky-linux/meson-example/1.0/recipe-sysroot-native/usr/bin/../lib/libgmodule-2.0.so.0 (0x00007fee8ccb2000)
libc.so.6 => /lib64/libc.so.6 (0x00007fee8c6c0000)
/home/adrian/projets/oss/poky/build-st/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fee8cdcd000)
libpcre2-8.so.0 => /home/adrian/projets/oss/poky/build-st/tmp/work/core2-64-poky-linux/meson-example/1.0/recipe-sysroot-native/usr/bin/../lib/./libpcre2-8.so.0 (0x00007fee8c655000)
Adrian: Did you try using the latest uninative from master? Also note that ldd is not accurate with our native binaries as it doesn't understand our uninative loader which changes the search path It was built via oe-selftest from master branch commit from 2025-08-03. I also checked that the uninative glibc version is >= the version on Fedora 42. So yes, that should be the case. Thanks for the hint with ldd. |