1236 2011-07-12 06:59:45 +0000 Broken ldd due to wrong path for ld.so 2011-08-19 03:42:37 +0000 1 1 7 Build System, Metadata & Runtime OE-Core devtools / tool chain unspecified x86 Multiple VERIFIED FIXED Patch sent out for review & merge High major 1.1 M4 1 jiajun.xu lianhao.lu ke.yu mark.hatle meta.mr.watcher meta.watcher richard.purdie sgw wenhuax.fan --- --- --- oldest_to_newest 14685 0 jiajun.xu 2011-07-12 06:59:45 +0000 Tree/Branch: Poky/1.1_M2 Poky Commit: 8df2a558b4d61778a669705b867969abe3514846 Meta Branch: 1.1_M2 Meta Commit: 92fc07a5f1b98779806cdcc2341487ff5ea5a238 For sugarbay(x86_64), ldd command does not work even I run it against a dynamic linked file. The issue is casused by wrong path pointed to ld.so in /usr/bin/ldd. ######## # We should be able to find the translation right at the beginning. TEXTDOMAIN=libc TEXTDOMAINDIR=/usr/share/locale RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2" warn= ######## But the real path on sugarbay is ######## root@sugarbay:~# ls /lib/ld-linux-x86-64.so.2 /lib/ld-linux-x86-64.so.2 ######## It will cause ldd not workable: ######## $ file /bin/ls /bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped $ ldd /bin/ls not a dynamic executable ######## 14701 1 sgw 2011-07-12 15:45:25 +0000 This needs more details, I tried to reproduce with qemux86-64, but was not able to. Since we do not have a sugarbay handy, I would like to know which image failed and maybe get an "strace" output from the ldd. 14721 2 sgw 2011-07-13 14:33:27 +0000 The issue is the eglibc that needs to be addressed as part of the multi lib, there is currently a workaround by linking /lib64 -> /lib, please use this until we resolve the bug ln -s /lib /lib64 14722 3 sgw 2011-07-13 14:34:02 +0000 The issue is the eglibc that needs to be addressed as part of the multi lib, there is currently a workaround by linking /lib64 -> /lib, please use this until we resolve the bug ln -s /lib /lib64 14723 4 mark.hatle 2011-07-13 14:41:32 +0000 both ldconfig.h and ldd need to be dynamically configured at build-time to know about all of the multilib directories within a configuration. ldd needs to know the appropriate places to search for an ld.so (and the corresponding ld.so name in that location) On IA32, the default is: /lib/ld-linux.so.2 and /lib64/ld-linux-x86_64.so But due to the way that OE allows the libdir to be arbitrarily changed, we need to be able to do the same. (Simply setting /lib64 as a symlink of /lib is a workaround, but not a fix for this issue. As a user could attempt to arbitrarily call it lib32, or libfoo, or libmyarch... these should allow work -- or at a minimum complain to the user that their setting will break ldconfig and ldd.) Also because these programs understand all of the ABI/multilib variants on a system, a full list of configured values will be needed to produce the correct values. (And to avoid install time file clashes in ldd, the values need to be the same in the 32-bit and 64-bit builds when multilibs are enabled.) 15082 5 lianhao.lu 2011-07-28 19:05:51 +0000 In order to get it work under the multilib situation, ldd and ldconfig.h need to know all the full path names for all the dynamic loaders(ld.so) in the current multilib configuration. The dynamic loader's full path names would be something like: ${base_libdir}/<ld.so name> We can get the ${base_libdir} for each variant in the multilib configuration by setting the correct TUNE name. The problem resides in the <ld.so name>. For i586 and x86_32, the ld.so name would be "ld-linux.so.2"; for x86_64 it would be "ld-linux-x86-64.so.2"; but for other ABI, I see names like "ld-linux.so.3", "ld.so.1", "ld64.so.1", etc. So the question is how we can get the correct ld.so names in the current multilib configuration? Hard code them in the TUNE configurations? 15231 6 lianhao.lu 2011-08-04 18:42:33 +0000 Patches in branch http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=llu/bug1236-oecore 15472 7 lianhao.lu 2011-08-15 18:04:47 +0000 Fixed by http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=375cf1561c0c9356a629495256423b44ddced9b6 and http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=fb2dfe7ac8e70d2969ebe14995900217e54716f6 15598 8 wenhuax.fan 2011-08-19 03:42:37 +0000 This issue fixed in Yocto1.1 20110817 build. And change the status to verified. Commit information: Tree/Branch: Poky/Master Meta Branch: Master Poky commit id: 978cdd5cb5b445f1cf406296444cb57cd8aa526a Image location: http://autobuilder02.yoctoproject.org/sugarbay-master/nightly/20110818-1/machines/sugarbay/x86_32/core-image-sato-sdk-sugarbay-20110818134503.hddimg.bz2