[MacPorts] #55382: cmake @3.10.0: Cannot find a C++ compiler supporting C++11 on this system

MacPorts noreply at macports.org
Fri Nov 24 20:05:15 UTC 2017


#55382: cmake @3.10.0: Cannot find a C++ compiler supporting C++11 on this system
-------------------------+-------------------------------------------------
  Reporter:  ryandesign  |      Owner:  michaelld
      Type:  defect      |     Status:  new
  Priority:  High        |  Milestone:
 Component:  ports       |    Version:
Resolution:              |   Keywords:  tiger leopard snowleopard lion
      Port:  cmake       |  mountainlion
-------------------------+-------------------------------------------------

Comment (by ryandesign):

 Replying to [comment:10 kencu]:
 > Been playing with variations of this for the morning. It's not an easy
 fix. The system libs are all installed with a different stdlib than cmake
 when you force libc++ on 10.7, so that all has to be rethought due to link
 errors. Frustratingly, the cmake internal libs don't build smoothly on
 some systems due to all the usual hassles like incorrect typedefs etc. No
 doubt fixable, but more time. And then the next version of cmake will come
 out, and we start over again.
 >
 > I thought perhaps gcc6 might build it (it does on PPC), but sadly even
 that failed on MacOS Intel.
 >
 > It's looking more tempting again to spin off the last version as a
 cmake-legacy port, and use that to step people through to building
 clang-4.0 or clang-5.0, and then use that to build the current cmake.
 However, automating that is not simple. People would probably have to
 follow a page of instructions.

 Perhaps you're now understanding why we previously reached the conclusion
 that C++11 on libstdc++ systems isn't workable?

 Maybe I can ask a different question: Why do we need cmake 3.10.0? Can we
 downgrade to 3.9.6 and keep it there indefinitely? Since 3.10.0 just came
 out, it seems unlikely that other projects will mandate that version of
 cmake for another couple years at least. Or, offer 3.10.0 or later to
 libc++ systems and 3.9.6 to libstdc++ systems. (This has the problem,
 though, that we also really need to add support to MacPorts base and
 mprsyncup for separate libc++ portindexes on older systems.)

 > And if they are going to have to do *that* -- well heck, might as well
 add it as a step to LibcxxOnOlderSystems and be done with it (and fix the
 buildbot stdlib thing).

 There is no "buildbot stdlib thing" to fix. Virtual machines destined to
 become buildbot workers for libc++ on 10.6, 10.7 and 10.8 have been
 provisioned for a year already. For them to become operational, we need
 to:

 1. decide how to differentiate libc++ packages from libstdc++ packages
 (e.g. how should we change the filename or server URL path)
 2. implement that decision in MacPorts base (and, if the server URL path
 changes, in the buildbot configuration)
 3. release a new version of MacPorts base
 4. install buildbot on the workers and follow the LibcxxOnOlderSystems
 instructions there

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


More information about the macports-tickets mailing list