1459 2011-09-06 08:55:11 +0000 cmake fails to execute on Ubuntu 10.04 LTS due to new GLIBC API Usage 2011-12-22 12:11:40 +0000 1 1 7 Build System, Metadata & Runtime OE-Core devtools / tool chain 1.0 x86 Multiple RESOLVED WONTFIX Medium major 1.2 1 sgw nitin.a.kamble meta.mr.watcher meta.watcher nitin.a.kamble --- --- --- oldest_to_newest 16048 0 sgw 2011-09-06 08:55:11 +0000 ERROR: Function 'do_configure' failed (see /srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/libproxy-0.4.6-r2/temp/log.do_configure.548 for further information) ERROR: Logfile of failure stored in: /srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/libproxy-0.4.6-r2/temp/log.do_configure.548 Log data follows: | DEBUG: SITE files ['endian-little', 'bit-32', 'ix86-common', 'common-linux', 'common-glibc', 'i586-linux', 'common'] | ERROR: Function 'do_configure' failed (see /srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/libproxy-0.4.6-r2/temp/log.do_configure.548 for further information) | cmake: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by cmake) NOTE: package libproxy-0.4.6-r2: task do_configure: Failed 16076 1 sgw 2011-09-07 11:01:19 +0000 Might be due to these symbols: U _ZNSt15_List_node_base7_M_hookEPS_@@GLIBCXX_3.4.14 U _ZNSt15_List_node_base9_M_unhookEv@@GLIBCXX_3.4.14 For glibc, there is GLIBC_COMPAT_SYMBOL, not sure if this can be used. I also saw something about .symver, whcih we might be able to set. 16077 2 nitin.a.kamble 2011-09-07 12:12:51 +0000 The issue is not with cmake, it is with the libstdc++ library which is using that symbol. The abi change is needed inside the libstdc++ code, which is coming from native/distro gcc. 16082 3 nitin.a.kamble 2011-09-07 17:02:06 +0000 I tried this on the autobuilder machine with the cmake binary built on my fedora15 system, and ldd fails like this: $ ldd cmake ./cmake: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by ./cmake) ./cmake: /lib/libc.so.6: version `GLIBC_2.14' not found (required by ./cmake) linux-vdso.so.1 => (0x00007fff7e7a7000) libdl.so.2 => /lib/libdl.so.2 (0x00007f73cb10f000) libidn.so.11 => /usr/lib/libidn.so.11 (0x00007f73caedc000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f73cabc7000) libm.so.6 => /lib/libm.so.6 (0x00007f73ca944000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f73ca72d000) libc.so.6 => /lib/libc.so.6 (0x00007f73ca3a9000) /lib64/ld-linux-x86-64.so.2 (0x00007f73cb31c000) 16093 4 sgw 2011-09-07 19:08:28 +0000 You can use nm cmake | grep List_node_base or nm cmake | grep memcpy, these will show the newer version of 3.4.14 (or 3.4.16) for List_node_base or for memcpy the newer GLIBC 2.14. If your build is fixed then those symbols will be the older 3.4 or 2.13 16102 5 nitin.a.kamble 2011-09-08 12:18:18 +0000 U _ZNSt15_List_node_base7_M_hookEPS_@@GLIBCXX_3.4.14 U _ZNSt15_List_node_base9_M_unhookEv@@GLIBCXX_3.4.14 These symbols are introduced in the libstd++ 3.4.14, so it won't be possible to find previous version of these symbols. When I compiled cmake natively on the failing autobuilder system these kinds symbols were not present in the cmake binary at all. BTW I could get memcpy to use the old abi using this line in all the files using memcpy __asm__(".symver memcpy,memcpy@GLIBC_2.2.5"); So only way to solve this issue is to link cmake statically. 16103 6 nitin.a.kamble 2011-09-08 12:21:29 +0000 just found out gcc has a option to just link libstdc++ statically leaving other libraries linked dynamically. I guess somebody else also has hit with similar kind of issue before, hence gcc has that option. -static-libstdc++ When the g++ program is used to link a C++ program, it will normally automatically link against libstdc++. If libstdc++ is available as a shared library, and the -static option is not used, then this will link against the shared version of libstdc++. That is normally fine. However, it is sometimes useful to freeze the version of libstdc++ used by the program without going all the way to a fully static link. The -static-libstdc++ option directs the g++ driver to link libstdc++ statically, without necessarily linking other libraries statically. 16142 7 nitin.a.kamble 2011-09-13 08:30:30 +0000 with the -static-libstdc++ option these errors are gone: U _ZNSt15_List_node_base7_M_hookEPS_@@GLIBCXX_3.4.14 U _ZNSt15_List_node_base9_M_unhookEv@@GLIBCXX_3.4.14 But the memcpy@@GLIBC_2.14 runtime linking error is not going away. It is issue if built on fedora15 or newer. I think older distros like fedora 14 may not have the issue because it they may not have glibc-2.14 I can make a patch to fix the part of the problem which should get autobuilder sstate working for now. But as mentioned earlier it is not going to work if cmake is built on fedora 15. 17833 8 sgw 2011-12-22 12:11:40 +0000 This will be handled differently by a check of the native sstate contents to determine if a rebuild is needed. see 1516