| Summary: | "runqemu" can't launch a qemu target image using toolchainSDK on FC16/Opensuse x86_64 machine. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Yocto Project Subprojects] ADT | Reporter: | Hongna Xu <hongnax.xu> | ||||
| Component: | kernel analysis | Assignee: | Robert Yang <liezhi.yang> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | Medium | CC: | inaky.perez-gonzalez, jessica.zhang, jiajun.xu, liang.li2, lianhao.lu, liezhi.yang, meta.mr.watcher, meta.watcher, nitin.a.kamble, poky.adt.watcher, poky.watcher, richard.purdie, sgw, yi.zhao, yp.sdk.watcher, yp.watcher, zhenfeng.zhao | ||||
| Version: | 1.2 | ||||||
| Target Milestone: | 1.2 M4 | ||||||
| Hardware: | x86 | ||||||
| OS: | Multiple | ||||||
| Whiteboard: | (1.2) patch review 30% | ||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||
| Verified: | Documentation change: | --- | |||||
| Bug Depends on: | 2251 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
Created attachment 327 [details]
launch qemu on FC16 x86-64
Add the attachment again.
THis looks like a host contamination case, where the native qemu is linked with host libraries. And it only happens to qemu that is created for meta-toolchain. *** Bug 1987 has been marked as a duplicate of this bug. *** I investigated this issue and it seems that while the build of the tools use the correct libraries from the tmp/sysroot area ldd qemu | grep libGL libGL.so => /intel/poky/builds/toolchain/tmp/sysroots/x86_64-nativesdk-pokysdk-linux/opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/lib/libGL.so (0x00007f70d3ab2000) The installed version in /opt/poky does not have libGL, libgcc, libstdc++ or libdrm installed. ldd /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/qemu /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/qemu: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libc.so.6: version `GLIBC_2.14' not found (required by /usr/lib64/libGL.so) /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/qemu: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libc.so.6: version `GLIBC_2.14' not found (required by /usr/lib64/libdrm.so.2) /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/qemu: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libc.so.6: version `GLIBC_2.14' not found (required by /usr/lib64/libstdc++.so.6) /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/qemu: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libc.so.6: version `GLIBC_2.14' not found (required by /lib64/libgcc_s.so.1) So the issue seems to be related to what gets put into the adt installer tarball. It has nothing to do with adt-installer, the problem will show using the sdk tarball which is build through bitbake meta-toolchain. The problem related to when qemu is built for meta-toolchain, it linked to the wrong libs I did some more testing, seems it only related to F16, it was fine on my F14 64bit as well, seems the F16 64bit libGL is at a different location? I don't have a F16 64bit machine at hand. Hongna, can you confirm the issue only shows up for F16 64bit? thx (In reply to comment #4) > I investigated this issue and it seems that while the build of the tools use > the correct libraries from the tmp/sysroot area > > ldd qemu | grep libGL > > libGL.so => > /intel/poky/builds/toolchain/tmp/sysroots/x86_64-nativesdk-pokysdk-linux/opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/lib/libGL.so > (0x00007f70d3ab2000) > Saul, which qemu did you "ldded"? qemu-native or qemu-nativesdk? On my Ubuntu 10.04 x86-64, the qemu-native or qemu-nativesdk always link to the ligGL under "/usr/lib/mesa/libGL.so" (In reply to comment #6) > I did some more testing, seems it only related to F16, it was fine on my F14 > 64bit as well, seems the F16 64bit libGL is at a different location? I don't > have a F16 64bit machine at hand. Hongna, can you confirm the issue only shows > up for F16 64bit? thx The meta-toolchain in /opt/poky does not have libGL, libgcc, libstdc++ or libdrm installed. So it uses host's ******************************************* libGL.so => /usr/lib64/libGL.so (0x0000003a58200000) libXext.so.6 => /usr/lib64/libXext.so.6 (0x0000003a41c00000) libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x0000003a58e00000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003a43800000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003a3e000000) ******************************************* On FC16 64bit, the /usr/lib64/libGL.so needes libc-2.14.so, but in native libGL we only have libc-2.13.so, so do libgcc, libstdc++ libXext and libdrm. On FC16 32bit,libGL.so => /usr/lib/libGL.so (0x4d7f7000) and it works. Paste Lianhao's investigation notes below for the context: ================================================================================ During the root causing of bug #1968(http://bugzilla.pokylinux.org/show_bug.cgi?id=1968), we find that on certain distributions, i.e. FC16 x86-64 and FC15 x86-64, the host libGL is asking for glibc 2.14. But the eglibc we provided in meta-toolchain is 2.13. This would prevent the user to launch the "qemu-nativesdk" from meta-toolchains. The "qemu-native" can be launched successfully on those platform thanks to that we don't have eglibc-native, so the host libGL will finally find the host libc which is compatible. I tried launching the "qemu-nativesdk" by LD_PRELOAD host libc, but it seems that the host libc is NOT compatible with our ld-linux-x86-64.so.2 either. I also tried launching the "qemu-nativesdk" by using the host dynamic linker with --inhibit-rpath options to keep the preconfigured RPATH from being used, but it seems that this option didn't have any effect. More data collected: For toolchain qemu, ldd -v shows: /usr/lib64/libGL.so: libdl.so.2 (GLIBC_2.2.5) => /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libdl.so.2 libc.so.6 (GLIBC_2.14) => not found libc.so.6 (GLIBC_2.4) => /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libc.so.6 libc.so.6 (GLIBC_2.3.4) => /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libc.so.6 libpthread.so.0 (GLIBC_2.2.5) => /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libpthread.so.0 /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libc.so.6: ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2 ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 For native qemu: /usr/lib64/libGL.so.1: libdl.so.2 (GLIBC_2.2.5) => /lib64/libdl.so.2 libc.so.6 (GLIBC_2.14) => /lib64/libc.so.6 libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6 libc.so.6 (GLIBC_2.3.4) => /lib64/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6 libpthread.so.0 (GLIBC_2.2.5) => /lib64/libpthread.so.0 And seems we only have recipe for eglibc-2.13 and 2.15 but no 2.14? Nitin and RP can you provide some thoughts? This is nasty. The trouble is libGL will want a newer libc and hence that is getting pulled into the dependencies and unsurprsingly, mixing two libcs together doesn't work well. The easiest solution would be to change the nativesdk libc to 2.15. I don't think we plan to do this for the target libc for 1.2 but we could change nativesdk's version if its well tested. Is there a possibility of installing distro version of libgl on the host to avoid the 2.14 libc dependency? on my fedora 16 system I am seeing this: $ ldd /usr/lib64/libGL.so.1.2 linux-vdso.so.1 => (0x00007fff2d9ea000) libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f5f6b91a000) libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f5f6b707000) libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00007f5f6b504000) libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00007f5f6b2fe000) libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00007f5f6b0f9000) libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00007f5f6aeed000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5f6acd1000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f5f6aacd000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f5f6a7c5000) libm.so.6 => /lib64/libm.so.6 (0x00007f5f6a541000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f5f6a32c000) libc.so.6 => /lib64/libc.so.6 (0x00007f5f69f75000) libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f5f69d5a000) librt.so.1 => /lib64/librt.so.1 (0x00007f5f69b52000) /lib64/ld-linux-x86-64.so.2 (0x00007f5f6bf02000) libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f5f6994e000) Building libGL that will work on many systems is too hard for us to want to consider (think binary only nvidia and so on). I meet with the same issue on opensuse 12.1 x86-64.
For toolchain qemu, ldd -v shows:
/opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libdl.so.2:
ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2
libc.so.6 (GLIBC_PRIVATE) => /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libc.so.6
/opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libc.so.6:
ld-linux-x86-64.so.2 (GLIBC_2.3) => /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2
ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2
For native qemu:
/usr/lib64/libGL.so:
libdl.so.2 (GLIBC_2.2.5) => /lib64/libdl.so.2
libc.so.6 (GLIBC_2.14) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.3.4) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
libpthread.so.0 (GLIBC_2.2.5) => /lib64/libpthread.so.0
this error also happened on 1.2 M4 RC1 from: http://autobuilder.yoctoproject.org/pub/nightly/20120328-1 git info :4d9f4d6ac25f39fe6d5491d05c7a26195bab648b git branch : 1.2_M4 os info : host : x86_64 kernel: 3.1.9-1.4-desktop #1 SMP PREEMPT run "runqemu nfs download_image/zImage-qemuarm.bin /home/yocto/test-yocto/arm/" and error info met below: ... Running qemu-system-arm... /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/qemu-system-arm -kernel download_image/zImage-qemuarm.bin -net nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=no,downscript=no -M versatilepb --no-reboot -show-cursor -usb -usbdevice wacom-tablet -no-reboot -m 128 --append "root=/dev/nfs nfsroot=192.168.7.1:/home/yocto/test-yocto/arm/,nfsvers=2,mountprog=21111,nfsprog=11111,udp,port=3049,mountport=3048 rw ip=192.168.7.2::192.168.7.1:255.255.255.0 mem=128M " /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/qemu-system-arm: error while loading shared libraries: libGL.so: cannot open shared object file: No such file or directory Set 'tap0' nonpersistent Releasing lockfile of preconfigured tap device 'tap0' Shutting down the userspace NFS server... runqemu-export-rootfs stop /home/yocto/test-yocto/arm/ Stopping rpc.mountd Stopping rpc.nfsd Removing exports file qemu can not start. There are workarounds for this issue,
For Opensuse 12.1 64bit:
export LD_PRELOAD="/lib64/libc.so.6"
would make it work
This is easy to fix since we can check and export LD_PRELOAD in the runqemu script.
But for Fedora 16 64bit, we need do:
export LD_PRELOAD="/lib64/libc.so.6"
ln -sf /lib64/ld-linux-x86-64.so.2 /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2
We need replace ld-linux-x86-64.so.2 because our ld-linux-x86-64.so.2 is not compatible
with fedora 16 64bit's, if we don't do this, the error message is:
/opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/qemu: relocation error: /lib64/libc.so.6: symbol _dl_starting_up, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference
I think that we have 2 methods for this bug currently:
1) Document the workaround, and we won't fix it.
2) Fix it in runqemu, and the fix would be:
If runqemu is in nativesdk:
If libGL.so requires GLIBC_2.14 and we don't supply and there is /lib64/libc.so.6:
export LD_PRELOAD="/lib64/libc.so.6"
check _dl_starting_up and replace the ld-linux-x86-64.so.2 if needed.
I prefer 1) which seems more safe, but I don't know the fault of 2).
Can someone please try setting PREFERRED_VERSION_eglibc-nativesdk = "2.15" as I think this should also resolve the problem. (In reply to comment #18) > Can someone please try setting PREFERRED_VERSION_eglibc-nativesdk = "2.15" as I > think this should also resolve the problem. I will try this on FC16 X86-64bit now, and will report the result when it has been done. (In reply to comment #18) > Can someone please try setting PREFERRED_VERSION_eglibc-nativesdk = "2.15" as I > think this should also resolve the problem. Cool, it works well on Fedora 16 64bit, I'd like to send a pull request for it after more testing, but where should we fix it, please? 1) Fix it in meta/conf/distro/include/tcmode-default.inc: Maybe change: PREFERRED_VERSION_eglibc-nativesdk ?= "${EGLIBCVERSION}" to: PREFERRED_VERSION_eglibc-nativesdk ?= "2.15" this seems not a right way, or any other file? 2) Document it other than fix it. (In reply to comment #20) > > Cool, it works well on Fedora 16 64bit, I'd like to send a pull request for it > after > more testing, but where should we fix it, please? > 1) Fix it in meta/conf/distro/include/tcmode-default.inc: > Maybe change: > PREFERRED_VERSION_eglibc-nativesdk ?= "${EGLIBCVERSION}" > to: > PREFERRED_VERSION_eglibc-nativesdk ?= "2.15" > > this seems not a right way, or any other file? > I believe we should change PREFERRED_VERSION_eglibc-initial-nativesdk also. Have you got a chance to test gcc-cross-canadian/gdb-cross-canadian besides the qmeu-nativesdk? (In reply to comment #21) > (In reply to comment #20) > > > > Cool, it works well on Fedora 16 64bit, I'd like to send a pull request for it > > after > > more testing, but where should we fix it, please? > > 1) Fix it in meta/conf/distro/include/tcmode-default.inc: > > Maybe change: > > PREFERRED_VERSION_eglibc-nativesdk ?= "${EGLIBCVERSION}" > > to: > > PREFERRED_VERSION_eglibc-nativesdk ?= "2.15" > > > > this seems not a right way, or any other file? > > > > I believe we should change PREFERRED_VERSION_eglibc-initial-nativesdk also. > Have you got a chance to test gcc-cross-canadian/gdb-cross-canadian besides the > qmeu-nativesdk? No, would you please give me more explanation? For example, the detailed steps:-), I'd like to test them with your directions. (In reply to comment #22) > > > > I believe we should change PREFERRED_VERSION_eglibc-initial-nativesdk also. > > Have you got a chance to test gcc-cross-canadian/gdb-cross-canadian besides the > > qmeu-nativesdk? > > No, would you please give me more explanation? For example, the detailed > steps:-), I'd like to test them with your directions. a simple way to do it is to follow https://bugzilla.yoctoproject.org/show_bug.cgi?id=1603#c9 (In reply to comment #23) > (In reply to comment #22) > > > > > > I believe we should change PREFERRED_VERSION_eglibc-initial-nativesdk also. > > > Have you got a chance to test gcc-cross-canadian/gdb-cross-canadian besides the > > > qmeu-nativesdk? > > > > No, would you please give me more explanation? For example, the detailed > > steps:-), I'd like to test them with your directions. > > a simple way to do it is to follow > https://bugzilla.yoctoproject.org/show_bug.cgi?id=1603#c9 and test if we can have a successful make. (In reply to comment #24) > (In reply to comment #23) > > (In reply to comment #22) > > > > > > > > I believe we should change PREFERRED_VERSION_eglibc-initial-nativesdk also. > > > > Have you got a chance to test gcc-cross-canadian/gdb-cross-canadian besides the > > > > qmeu-nativesdk? > > > > > > No, would you please give me more explanation? For example, the detailed > > > steps:-), I'd like to test them with your directions. > > > > a simple way to do it is to follow > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=1603#c9 > > and test if we can have a successful make. thanks, autoreconf/configure/make worked well (without PREFERRED_VERSION_eglibc-initial-nativesdk) If we make this change in tcmode-default.inc which I believe is the right place, we also need to change PREFERRED_VERSION_eglibc-initial-nativesdk as these versions need to match ideally. Merged in master: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=a0ccc1fb24f45da3688ce3cde09107e71b6de561 toolchain from: http://autobuilder.pokylinux.org/nightly/20120412-2/toolchain/ when used on ubuntu 11.10 x86_64 host,error found below when run "runqemu-extract-sdk": runqemu-extract-sdk core-image-sato-sdk-qemuarm-20120412211904.rootfs.tar.bz2 rootfs_dir Creating directory rootfs_dir Extracting rootfs tarball using pseudo... /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr/bin/pseudo -P /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr tar -C "rootfs_dir" -xjf "core-image-sato-sdk-qemuarm-20120412211904.rootfs.tar.bz2" tar: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr/lib/pseudo/lib64/libpseudo.so) Warning: I don't see many files in /home/liangli/test-yocto/arm Please double-check the extraction worked as intended ---------------- also when run ./adt_installer on ubuntu 11.10 x86_64 host,following error is found: ..... Successfully installed selected native ADT! Installing target sysroot for arch: arm, rootfs type: sato-sdk, location: /root/test-yocto/arm_1.2_new Creating directory /home/test-yocto/arm_1.2_new... Extracting rootfs: core-image-sato-sdk-qemuarm.tar.bz2, using pseudo... ############################################################################# # Meet error(s) when installing Yocto ADT! Please check log file for details. ############################################################################# and following error is found in adt_installer.log: [ADT_INST] Do you want to continue installation? Please enter Y/N: Creating directory /home/test-yocto/arm_1.2_new... Extracting rootfs: core-image-sato-sdk-qemuarm.tar.bz2, using pseudo... tar: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr/lib/pseudo/lib64/libpseudo.so) the above error not found in 1.2 M4 rc2 test. This sounds like pseudo is being extracted into the native sysroot but the corresponding libc is not? ldd -v /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr/bin/pseudo /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr/bin/pseudo: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr/bin/pseudo) linux-vdso.so.1 => (0x00007fffc65ff000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f5b1a79e000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5b1a59a000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5b1a1f8000) /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f5b1a9d3000) Version information: /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr/bin/pseudo: libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2 libpthread.so.0 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libpthread.so.0 libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.14) => not found libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libpthread.so.0: ld-linux-x86-64.so.2 (GLIBC_2.2.5) => /lib64/ld-linux-x86-64.so.2 ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2 ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libdl.so.2: ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libc.so.6: ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2 ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 (In reply to comment #29) > This sounds like pseudo is being extracted into the native sysroot but the > corresponding libc is not? I don't think so, please see the ldd result of pseudo: $ ldd -v //opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr/bin/pseudo linux-vdso.so.1 (0x00007fff9e5ff000) libpthread.so.0 => /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/lib/libpthread.so.0 (0x00007f0e7863d000) libdl.so.2 => /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/lib/libdl.so.2 (0x00007f0e78439000) libc.so.6 => /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/lib/libc.so.6 (0x00007f0e78094000) /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2 (0x00007f0e7885a000) Version information: //opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr/bin/pseudo: libdl.so.2 (GLIBC_2.2.5) => /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/lib/libdl.so.2 libpthread.so.0 (GLIBC_2.2.5) => /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/lib/libpthread.so.0 libc.so.6 (GLIBC_2.3) => /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/lib/libc.so.6 libc.so.6 (GLIBC_2.3.4) => /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/lib/libc.so.6 libc.so.6 (GLIBC_2.14) => /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/lib/libc.so.6 But the result of libpseudo.so: $ ldd -v /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr/lib/pseudo/lib64/libpseudo.so /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr/lib/pseudo/lib64/libpseudo.so: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr/lib/pseudo/lib64/libpseudo.so) linux-vdso.so.1 => (0x00007fff341ff000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f52c77c0000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f52c75a4000) libc.so.6 => /lib64/libc.so.6 (0x00007f52c7225000) /lib64/ld-linux-x86-64.so.2 (0x0000003908a00000) Version information: /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr/lib/pseudo/lib64/libpseudo.so: libdl.so.2 (GLIBC_2.2.5) => /lib64/libdl.so.2 libpthread.so.0 (GLIBC_2.2.5) => /lib64/libpthread.so.0 libc.so.6 (GLIBC_2.3) => /lib64/libc.so.6 libc.so.6 (GLIBC_2.3.4) => /lib64/libc.so.6 libc.so.6 (GLIBC_2.14) => not found libc.so.6 (GLIBC_2.7) => /lib64/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6 Seems there is rpath in libpseudo.so, I don't think this is the same issue as before, the runqemu works well. I'd like to file another bug and work on the libpseudo.so today. My ldd -v /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr/bin/pseudo works well, but ldd -v /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr/lib/pseudo/lib64/libpseudo.so doesn't work, which sdk do you use please? Mine is: http://autobuilder.pokylinux.org/nightly/20120412-2/toolchain/x86-64/poky-eglibc-x86_64-arm-toolchain-gmae-1.2.tar.bz2 I will colse this one and file another one since they are not the same issue, the runqemu works well. (In reply to comment #30) > ldd -v /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr/bin/pseudo > /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr/bin/pseudo: > /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by > /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr/bin/pseudo) > linux-vdso.so.1 => (0x00007fffc65ff000) > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 > (0x00007f5b1a79e000) > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5b1a59a000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5b1a1f8000) > /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2 => > /lib64/ld-linux-x86-64.so.2 (0x00007f5b1a9d3000) > > Version information: > /opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr/bin/pseudo: > libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2 > libpthread.so.0 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libpthread.so.0 > libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.14) => not found > libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > /lib/x86_64-linux-gnu/libpthread.so.0: > ld-linux-x86-64.so.2 (GLIBC_2.2.5) => /lib64/ld-linux-x86-64.so.2 > ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2 > ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 > libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > /lib/x86_64-linux-gnu/libdl.so.2: > ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 > libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > /lib/x86_64-linux-gnu/libc.so.6: > ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2 > ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 They are not the same issues, mark it as fixed, please refer to: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2299 (In reply to comment #16) > this error also happened on 1.2 M4 RC1 from: > http://autobuilder.yoctoproject.org/pub/nightly/20120328-1 > > git info :4d9f4d6ac25f39fe6d5491d05c7a26195bab648b > git branch : 1.2_M4 > > os info : > host : x86_64 > kernel: 3.1.9-1.4-desktop #1 SMP PREEMPT > > run "runqemu nfs download_image/zImage-qemuarm.bin /home/yocto/test-yocto/arm/" > and error info met below: > ... > Running qemu-system-arm... > /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/qemu-system-arm > -kernel download_image/zImage-qemuarm.bin -net nic,vlan=0 -net > tap,vlan=0,ifname=tap0,script=no,downscript=no -M versatilepb --no-reboot > -show-cursor -usb -usbdevice wacom-tablet -no-reboot -m 128 --append > "root=/dev/nfs > nfsroot=192.168.7.1:/home/yocto/test-yocto/arm/,nfsvers=2,mountprog=21111,nfsprog=11111,udp,port=3049,mountport=3048 > rw ip=192.168.7.2::192.168.7.1:255.255.255.0 mem=128M " > /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/qemu-system-arm: > error while loading shared libraries: libGL.so: cannot open shared object file: > No such file or directory > Set 'tap0' nonpersistent > Releasing lockfile of preconfigured tap device 'tap0' > Shutting down the userspace NFS server... > runqemu-export-rootfs stop /home/yocto/test-yocto/arm/ > Stopping rpc.mountd > Stopping rpc.nfsd > Removing exports file > > qemu can not start. the error not found on 1.2 M4 RC3 from: http://autobuilder.yoctoproject.org/pub/nightly/20120412-2 "runqemu" can launch qemu target image normally. test env: host: opensuse 12.1 x86_64 kernel: 3.1.9-1.4-desktop #1 SMP PREEMPT git info: fae1c7a5fdcea199338b5f91efaafd7c72aec5dd git branch: 1.2_M4 ToolchianSDK from ADT-installer and meat-toolchain could launch qemu target image normally, and until now found no impact on other features, so i set the status verified fixed, if anyone encounters it, pls reopen it. test env: host: opensuse 12.1 x86_64&Fedora 16 x86_64 git branch: 1.2_M4 (tagged rc3) git info: fae1c7a5fdcea199338b5f91efaafd7c72aec5dd |
Untar the meta-toolchain tarball as normal and source the environment from meta-toolchain tarball, then run the command:runqemu ${TARGET_ARCH_KERNEL} ${TARGET_ROOTFS} , I got the log as attachment. BTW, FC16 32bit machine can launch it normally.