C++11 on Mountain Lion and lower?

[Clemens Lang]

Hi,

On Wed, Dec 04, 2013 at 10:52:28AM +0100, Titus von Boxberg wrote:
> maybe I got lost in this thread but I think multiple issues get mixed
> up.

Yes, I think some things are getting mixed up here, but only because we
cannot handle them separately. The available C++ runtimes are in fact
determined by the OS and we're not completely independent from the OS in
choosing a C++ runtime implementation for MacPorts.

> - The only C++ runtime that Apple provides on all systems since 10.5(?)
>   is the one delivered with gcc 4.2.1. I really doubt that Apple
>   will change that to a recent libc++

libc++ has been available for a while now, but was not the default. I
think it was first shipped in 10.6(?), although the older versions
probably have their own set of problems related to compiling C++11 code.

> - I don't see what the question of C++11 support and thus
>   the c++ library version has to do with the OSX version besides,
>   presumably, that 10.9 is the first OSX release with full (?) C++11
>   support in the preinstalled C++ standard library.
>   macports provides two recent C++ implementations, clang/libc++ and
>   FSF g++, that both work on systems earlier than 10.9

It does matter in the sense that OS X ships a number of libraries that
export a C++ API. The runtime these libraries use should also be the
runtime MacPorts uses for all its own stuff, because while we can avoid
using them in our ports, we might not be able to stop users from using
them and libraries built from MacPorts in their own software.

A question that still remains is how many of the libraries shipped with
OS X actually offer C++ APIs. If there's only a few minor libraries we
could disregard the compatibility problem here, document that those
shouldn't be used when linking against libs from MacPorts and choose a
C++ runtime independent of the system-provided one. That would solve our
C++11 issues, because we could either use a recent (MacPorts-provided)
libc++ or a recent (MacPorts-provided) libstdc++ for C++11 support (and
thus also for _all_ other ports).

> - I doubt but don't know whether there are any other C++ libraries
>   in /usr/lib (besides a stone old implementation of wxWidgets on 10.6)
>   Using them within macports would collide with the macports
>   philosophy not to use more of the base system than necessary.

Yes, but as I said, MacPorts building its own ports is not the only
issue here, users trying to build their stuff is just as relevant.

> - An executable loading more than one implementation of the
>   C++ standard library is asking for undefined behaviour.
> - You should not mix up different C++ standard libs in
>   one address space, regardless of whether both are libstdc++ or not.
>   It's the job of macports to ensure that for the C++ executables
>   it compiles.

That essentially means we can not support C++11 on Mountain Lion and
below at the moment. We need to switch to a different C++ runtime first.

> - more and more C++ ports will start to require C++11, or at least
>   newer C++ implementations than the the one shipped with the
>   ubiquitous gcc 4.2.1

Obviously C++11 support is a problem we're going to face sooner or
later. It is a problem now and I don't think just avoiding C++11 on
older systems is going to cut it.

> - currently, there might still be some ports that require g++

Which is fine as long as they don't any C++ API (we all know that, but
just as a reminder).

> How many C++ ports really require something newer than gcc 4.2.1?
> Are they used by many macports installations?
> How does the estimated growth rate of these ports relate to
> the estimated phase out rate of older OSX installations?
> In short, how bad is the pain to drop the idea of C++11 on OSX < 10.9?
> And the other way round:
> Down to which OSX version shall macports be responsible for providing
> a recent C++ runtime and how much effort should that take?

That's the right set of questions. Unfortunately I don't have an answer.
At the moment it seems to me C++11 on systems < 10.9 is going to be a
feature ports (and users!) will request. If I remember correctly there
have been a number of questions on how to compile C++11 code on these
systems, even before we discussed the runtime mixing problem on this
list.

> I don't know macports well enough to answer these questions,
> but here are some guesses trying to be educated:
> The only C++ runtime on osx that I'd expect to have long term support
> is clang/libc++. Then I'd first rule out using a newer self-built g++
> since that collides with the reasons to use clang/libc++, anyway.

We don't need long-term support, because it's obvious that on systems
that use libc++ as default runtime we're going to use that. The question
we're facing is what to do on systems that still use libstdc++ as
default runtime. clang can compile against libstdc++ just fine and if we
can convince it to compile against MacPorts libstdc++ that would be a
viable solution, IMO.

> My second guess is that I'd drop the whole idea of macports providing
> its own C++ implementation ;-)

Which would also mean not supporting C++11 on systems < 10.9. As I
mentioned before, we've had users ask for C++11 support on these systems
and I think there is a need for that.

-- 
Clemens Lang