Bug 1459

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.

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.

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)

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

      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.

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.

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.

This will be handled differently by a check of the native sstate contents to determine if a rebuild is needed. see 1516