> On Jan 11, 2015, at 01:47, René J.V. Bertin <[email protected]> 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).
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
