[MacPorts] #59832: cmake 3.16.0: does not build on PPC Mac OS X 10.5.8, "Bus Error"

[MacPorts]

#59832: cmake 3.16.0: does not build on PPC Mac OS X 10.5.8, "Bus Error"
--------------------------+-----------------------
  Reporter:  timishimuni  |      Owner:  michaelld
      Type:  defect       |     Status:  assigned
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:  2.6.2
Resolution:               |   Keywords:  leopard
      Port:  cmake        |
--------------------------+-----------------------

Comment (by noloader):

 Replying to [comment:24 kencu]:
 > indeed. I had a long email exchange with upstream in Nov/Dec about this.
 They know exactly what the issue is, and some others have seen this before
 (frederic).
 >
 > object gets newed by one libstdc++, and is attempted to be freed by the
 other, just like we always worried about.
 >
 > we can set DYLD_LIBRARY_PATH  in macports environ to work around
 it...iirc that worked fine to make cmake work with 10.5.
 >
 > that's logically the same as replacing libstdc++, of course, at least
 for the new softwae.
 >
 > That might be our best bet, actually, as I want to get this idea also
 working to use a newer libc++ on the newer systems anyway...

 Forgive my ignorance again... Apple linkers in 10.1 and above support two
 level namespaces. Would a linker namespace help sidestep the problem of
 allocating in one dylib, and freeing in another dylib? I believe the
 linker option is `-twolevel_namespace`. There is also an option
 `-twolevel_namespace_hints`.

 I have only used the flat namespace, so I have no practical experience
 with multiple linker namespaces.

 Also see
 [http://mirror.informatimago.com/next/developer.apple.com/releasenotes/DeveloperTools/TwoLevelNamespaces.html
 Two-Level Namespace Executables].

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