C++11 on Mountain Lion and lower?

[Clemens Lang]

On Tue, Dec 03, 2013 at 07:48:48PM +0000, Christopher Jones wrote:
> For that last one, it is not necessary to have Apple make that
> decision. macPorts could decide to release the current trunk, and
> force the use of libc++ on systems older than OSX10.9. This of course
> would force all users to recompile all their ports, and probably is
> not a solution for all OSX releases, as I guess the older ones
> probably don’t have any runtime supporting c++11….

That would still require users that want to build their own C++ software
to only use C++ APIs from libraries compiled by MacPorts. Strictly no
linking against any C++ APIs provided by the OS in /usr/lib/*.dylib.

I'm not sure that's what we currently want.

> To be honest, if it isn’t possible to do it properly, I would go with
> the top one above. At least it doesn’t pretend all is OK, when it
> isn’t. If upstream for a given port decides they are going to use
> c++11 features, unconditionally, they effectively they are making that
> decision for us.

I'd do that if only systems below Lion were affected, but this would
mean the port doesn't work on Mountain Lion and Mavericks has just been
released, so I guess the majority of our user base still is on ML.

I think the FSF GCC solution involving libstdc++ from MacPorts is good
enough for now, even if it is a hack. Reading the documentation on ABI
compatibility for libstdc++ mentions all releases since GCC 4.3 use
libstdc++.6.so (on Linux) as SONAME and should be compatible. The docs
also explicitly mention they libstdc++ libraries are forward-compatible,
so in theory one should always be able to substitute a libstdc++ library
with a newer version. Of course, I'm not sure whether this also holds
for multiple libstdc++ versions in the same address space.

-- 
Clemens Lang