On Tue, Apr 14, 2015 at 10:23 AM, René J.V. <rjvber...@gmail.com> wrote:
> >The main problem is that Apple's own C++ stuff is based on either a > >pre-C++11 libstdc++ or a C++11 libc++. You could probably build an > official > >GPL3-d libstdc++ with C++11 support and it would probably even work (that > > If that is equivalent to replacing the system libstdc++ with the one from > port:gcc-4x then no, that doesn't work. Or rather, it seemed to work just > fine until I had to reboot. Then things started to fail. > I was not talking about actually replacing the system libstdc++; you get what you deserve if you do that. I would expect something linking against an alternative libstdc++ to have some chance to work, though. > >being one of the points of C++11) but might not be able to distribute the > >resulting objects/binaries because of conflicts between GPL and Apple's > >licenses. > > How large an intersection would there be between the users on old(er) OS X > versions who require a C++11 compatible libstdc++ and those who ship > commercial binaries? > I was thinking more (a) buildbots (b) tossing the result on a web page for others to download instead of having to do the whole weird setup themselves. > (PS: we're talking about the equivalent of Microsoft's msvc runtimes, no?) > Not exactly, as that includes libc. This is just the glue that allows C++ objects to work and be shared between components; things blow up if some components expect a C++11-compatible object and get a pre-C++11 object, or vice versa. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
