libc++, C++11, and C++14 on Leopard and Snow Leopard

[Jeremy Huddleston Sequoia]

> On Jan 11, 2015, at 01:47, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> 
> On Sunday January 11 2015 00:39:37 Jeremy Huddleston Sequoia wrote:
>> I spent a few days over the holidays getting libc++ working on Leopard/Intel.  Over the past week or so, I've tested this configuration and fixed various issues that surfaced.  As I now have all of my normal ports built and installed on Leopard in this configuration, I think it's now ready for a wider audience.
> 
> I hope the new year doesn't start only now because of that, Jeremy! :)
>> 
>> This brings a modern toolchain back to OS X Leopard, so users still on that old OS can have C++11 and C++14 support and install ports that require it.  These instructions apply to Snow Leopard as well.  Snow Leopard has had this support since the end of 2012, but I don't think I ever sent out detailed instructions, and the bootstrapping is much simpler now as well.
> 
> 
> Wow.. This is really great news. Pity that it can quickly get almost prohibitively cumbersome.
> 
> Couple question:
> - Will this change ever be picked up by the buildbots?

I doubt it.  There aren't Leopard buildbots as is.

> - what's the point in (re)installing clang-3.4 if you already have clang-3.5 in order to do that?

Good catch.  At the time I initially wrote it and was taking notes, I hadn't yet gotten clang-3.5 working on Leopard, so I actually built 3.3 to rebuild 3.4.  Now that 3.5 is building, you can just uninstall 3.4 after installing 3.5.

The point of the re-install is just to get llvm-3.4 and clang-3.4 built using libc++ rather than libstdc++.

> - Am I right that the new libc++ will co-exist with with the system libstdc++?

Yes, just like it does on Lion and newer versions of OS X.

> - If so, how can this work if there are system SDKs that contain built C++ code?

As long as you're not passing C++ objects from one runtime to the other, you should be fine.  See the discussion in the archives (1-2 years ago?) when we consolidated libstdc++ from all the gcc ports) about why this can be problematic.  Differences in symbol mangling between libstdc++ and libc++ mean that this is not even possible to build an app that would have this kind of problem between libc++ and libstdc++ (it would fail at link time). 

> - With these changes, can one still safely use the MacPorts clang compiler(s) for software outside of MacPorts without fear of running into C++ runtime issues?

Yes, the system compilers will continue to use libstdc++, the MacPorts clang compilers will continue to use libstdc++ by default.  You just now have the option of using libc++ if you want to by using a MacPorts clang++ compiler with -stdlib=libc++ on the command line.  You can install the libc++ runtime and keep MacPorts using libstdc++ (its default) if you want, and you'd be in the same boat as Lion and Mountain Lion users (libc++ would be available if desired but not default).

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