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 _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
