cmake @3.9.5: dyld: lazy symbol binding failed: Symbol not found: __ZSt11_Hash_bytesPKvmm

[ryandesign (Ryan Carsten Schmidt)]

The cmake 3.9.5 binary produced by the 10.8 buildbot worker does not run on my 10.8 test system:

$ sudo port -n upgrade --force cmake
Password:
--->  Fetching archive for cmake
--->  Attempting to fetch cmake-3.9.5_0.darwin_12.x86_64.tbz2 from https://packages.macports.org/cmake
--->  Attempting to fetch cmake-3.9.5_0.darwin_12.x86_64.tbz2.rmd160 from https://packages.macports.org/cmake
--->  Computing dependencies for cmake
--->  Deactivating cmake @3.9.5_0
--->  Cleaning cmake
--->  Uninstalling cmake @3.9.5_0
--->  Cleaning cmake
--->  Computing dependencies for cmake
--->  Installing cmake @3.9.5_0
--->  Activating cmake @3.9.5_0
--->  Cleaning cmake
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  Found 5 broken files, matching files to ports      
--->  Found 1 broken port:
     cmake @3.9.5 
         /opt/local/bin/ccmake
         /opt/local/bin/cmake
         /opt/local/bin/cmakexbuild
         /opt/local/bin/cpack
         /opt/local/bin/ctest
$ cmake --version
dyld: lazy symbol binding failed: Symbol not found: __ZSt11_Hash_bytesPKvmm
  Referenced from: /opt/local/bin/cmake
  Expected in: /usr/lib/libstdc++.6.dylib

dyld: Symbol not found: __ZSt11_Hash_bytesPKvmm
  Referenced from: /opt/local/bin/cmake
  Expected in: /usr/lib/libstdc++.6.dylib

Trace/BPT trap: 5
$

After rebuilding from source, it works:

$ sudo port -ns upgrade --force cmake
--->  Computing dependencies for cmake
--->  Fetching distfiles for cmake
--->  Attempting to fetch cmake-3.9.5.tar.gz from https://distfiles.macports.org/cmake
--->  Verifying checksums for cmake
--->  Extracting cmake
--->  Applying patches to cmake
--->  Configuring cmake
--->  Building cmake
--->  Staging cmake into destroot
--->  Deactivating cmake @3.9.5_0
--->  Cleaning cmake
--->  Uninstalling cmake @3.9.5_0
--->  Cleaning cmake
--->  Computing dependencies for cmake
--->  Installing cmake @3.9.5_0
--->  Activating cmake @3.9.5_0
--->  Cleaning cmake
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  No broken files found.                             
$ cmake --version
cmake version 3.9.5

CMake suite maintained and supported by Kitware (kitware.com/cmake).
$

I don't know if this affects other OS versions; Mountain Lion is just where I experienced it.

[michaelld (Michael Dickens)]

c++filt __ZSt11_Hash_bytesPKvmm -> std::_Hash_bytes(void const*, unsigned long, unsigned long)

As far as I can tell, std::_Hash_bytes is provided only by GCC, not clang (of any sort / elk). So this issue might just affect 10.8 and prior users. Further, the header that includes the hash_bytes one ("typeinfo"), only does so if the C++ version is C++11 -- which should not be the case any longer (after reverting the commit requiring it for building the cmake release). So ... I'm a little at a loss as to what's going. Hopefully other users don't experience this issue. I'll try checking on my 10.8 install & see what I can.

[ryandesign (Ryan Carsten Schmidt)]

What I think has happened is that on the 10.6, 10.7, and 10.8 buildbot workers, cmake 3.9.5 did actually build a binary while using the cxx11 1.1 portgroup, but it was not functional, in the way shown in this ticket, and it was not distributable because of something in the large compiler dependency chain. When you committed [44373e0fd9955702e9e2f6820b2cf595fec24c65/macports-ports], reverting [c8d94a92cb1d690a3dc052ff1ed7c0107af9b32a/macports-ports], the large compiler dependency chain went away, making it distributable again, so it distributed the nonfunctional binary it built before.

I can see that the "bad" cmake binary is linked with libgcc's libstdc++:

$ otool -L /opt/local/bin/cmake
/opt/local/bin/cmake:
	/opt/local/lib/libexpat.1.dylib (compatibility version 8.0.0, current version 8.7.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/opt/local/lib/libarchive.13.dylib (compatibility version 17.0.0, current version 17.2.0)
	/opt/local/lib/libcurl.4.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/local/lib/libuv.1.dylib (compatibility version 2.0.0, current version 2.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 744.19.0)
	/opt/local/lib/libgcc/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.24.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)

while the "good" cmake binary is linked with OS X's libstdc++:

$ otool -L /opt/local/bin/cmake
/opt/local/bin/cmake:
	/opt/local/lib/libexpat.1.dylib (compatibility version 8.0.0, current version 8.7.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/opt/local/lib/libarchive.13.dylib (compatibility version 17.0.0, current version 17.2.0)
	/opt/local/lib/libcurl.4.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/local/lib/libuv.1.dylib (compatibility version 2.0.0, current version 2.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 744.19.0)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)

10.5 ppc was unaffected because clang doesn't work on ppc so it didn't build a faulty binary, and when the clang compiler dependency was removed it built and distributed a good binary.

So I think you can fix the problem for 10.6, 10.7, and 10.8 by revbumping cmake.

[ryandesign (Ryan Carsten Schmidt)]

Actually, looking at the binaries from the packages server, only the Mountain Lion one is linked with /opt/local/lib/libgcc/libstdc++.6.dylib so maybe only Mountain Lion was affected. Still, a revbump should take care of it.

[michaelld (Michael Dickens)]

Forgot to tag the commit, sorry!

Done in [5504232bfb8e4ec05a4b120a5de593d0cf6ecbb3/macports-ports].

[kencu (Ken)]

I am still confused by why this symbol was not found. cmake should be able to build without trouble using the cxx11 1.1 PortGroup. The undefined symbol should not have occurred. Using the cxx11 1.1 PG, cmake should have been linked against /opt/local/lib/libstdc++.6.dylib instead of /usr/lib/libstdc++.6.dylib.

I have also seen issues with std::Hash before, but it was a while back and I couldn't fix it then. I think this is not the only example of this.

I think this might underscore some other incompatibility with clang-5.0 and gcc's libstdc++ / gcc7's headers that we have yet to resolve, and that might show up again somewhere.

[kencu (Ken)]

I wonder if this could have been due to cmake's bootstrapping build not picking up the cxx11 1.1 PortGroup's "fixes" in the second "cmake building cmake" build.

[ryandesign (Ryan Carsten Schmidt)]

Well it said all compilers were blacklisted, which means the port is expected not to build or not to work, and I really don't know why MacPorts then tries to build the port anyway with one of the blacklisted compilers; it should just exit with the error. If on the other hand the port is expected to build and work, then the blacklisting is wrong.