C++11 on Mountain Lion and lower?

[Christopher Jones]

Hi,

On 3 Dec 2013, at 8:13pm, Clemens Lang <cal at 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
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2030 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20131203/fe3f5877/attachment.p7s>