[MacPorts] #55272: cmake @3.9.5: dyld: lazy symbol binding failed: Symbol not found: __ZSt11_Hash_bytesPKvmm

[MacPorts]

#55272: cmake @3.9.5: dyld: lazy symbol binding failed: Symbol not found:
__ZSt11_Hash_bytesPKvmm
-------------------------+--------------------------
  Reporter:  ryandesign  |      Owner:  michaelld
      Type:  defect      |     Status:  new
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:
Resolution:              |   Keywords:  mountainlion
      Port:  cmake       |
-------------------------+--------------------------

Comment (by ryandesign):

 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.

--
Ticket URL: <https://trac.macports.org/ticket/55272#comment:2>
MacPorts <https://www.macports.org/>
Ports system for macOS