On Mon, Sep 8, 2014 at 2:44 PM, Brandon Allbery <allber...@gmail.com> wrote:
> So the cases here are: > > - pre-C++11 C++ support must use the system libstdc++ (the binary-only > backward compatibility one on newer systems whose development C++ runtime > is libc++). > > - C++11 C++ support must either face the license issue of a later > libstdc++ or use libc++. In either case, the system C++ runtime cannot be > used on older systems. On newer systems where Apple shipped C++11, the > system runtime is libc++ and C++11 compatible, so use it. > > - The case of pre-C++11 libc++ does not come up because Apple has not to > my knowledge ever shipped this. > > In summary, on pre-C++11 systems you need to provide a different C++ > runtime no matter what; on C++11 systems you can always use Apple's runtime. > I should probably also mention the implication that the only options for code on older OS X that uses any C++ frameworks from Apple are: - use the modern libstdc++, which may mean building locally and not distributing any binaries which might involve combining it with non-GPL3 code --- assuming that it has backward compatibility support for pre-C++11 g++ objects / libraries; or - find someone who can clean-room the API *and ABI* details for pre-C++11 libstdc++, and then someone else (necessarily to avoid license issues) to use that clean-room information to add compatibility to libc++. Simply providing libc++ on older systems is not sufficient for this case, because it won't interoperate with pre-C++11 compiled objects or libraries from Apple. -- 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
