C++11 on Mountain Lion and lower?

[Titus von Boxberg]

Hi Clemens, all,

you dropped the last text block from my mail where I said
that I think that macports shouldn't care much
about users using macports libraries for their own software.

This is why also in your mail quoted below in my opinion these
things get mixed up: you mix up users of macports executables with
developers using macports libraries.

Again, only as a recommendation:
macports shouldn't care about this "c++11 library use case"
(if it's not cheap, and I guess that it wouldn't be).

Developers wanting to use C++11 should be using 10.9.
As said, (only) on this system, using clang from xcode 5,
it comes with (almost) no extra cost for macports
to have the whole port set moved to a c++11 compliant
runtime (which reenables C++11 developers to use
the libraries compiled by macports for their own software).

C++11 developers really targeting earlier systems then are on their own.
And spoken from my experience, they aren't lost since macports
already provides compliant implementations also for systems < 10.9.
I simply wouldn't spend the time to make it use them for its
own purposes (that is, the executables it compiles).

Basically, all this boils down to following recommendations:
- tell c++11 developers to use 10.9+Xcode 5
   (presumably, they will know already).
- mark all ports requiring the new runtime as unavailable
   on systems < 10.9

Some smaller comments below.

Regards,
Titus

Am 04.12.2013 12:29, schrieb Clemens Lang:
> Hi,
>
> 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'm using only the Darwin / POSIX subset of MacOS together with Qt or 
wxWdigets, so I don't know.
Does OSX really offer (so many) C++ APIs?


>
>> - 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.

Why "yes"? Did you mean "no"? Otherwise this contradicts what you said 
above. Or are you intermixing C and C++?


>> - 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).

I really meant "g++" (to compile C++). That always uses C++ API/ABIs.
I didn't mean the ports that require the C (or even the FORTRAN) part of 
gcc.

>
>> 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.

Again, I don't know. But I really doubt that you could convince
clang++ to offer a fully compliant C++11 implementation when using any
version of libstdc++. I would try to not even think about that
since it's nonstandard (at least for Apple).

As said above: since libc++ is - from 10.9 onwards - the only
officially supported implementation macports really should stay with it.

>
>> 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.
>
Again: Where is the need coming from? From within macports (executables) 
or from users of C++ libs compiled by macports.