Hi, On 3 Dec 2013, at 8:13pm, Clemens Lang <c...@macports.org> wrote:
> 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. Nope, nor do I. Just mentioning it… > >> 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. Oh, I agree it sucks. But still I feel this is kinda upstreams decision to make. Is this issue due to a new change in an upstream version ? Have we got in contact with the upstream devs to find out what their intentions are, and if they know this effectively rules out all OSX versions before 10.9 ? If they still insist, I am not sure we should second guess them... > > 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. Well yes, you can drop in a newer libstdc++ as a replacement for an older one, and applications linked against the old one should still work. The issue is that last point, about an application loading *both* runtimes at the same time. That I think can cause issues and should be avoided. I guess you can check with otool -L to see if this is happening with your hack ? Chris > > -- > Clemens Lang >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
