[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