Re: Supporting C++11 on old OS X (Was: kdevelop 4.7 and beyond (was: clang++-mp-3.4 doesn't find initializer_list on OS X 10.6))
On Mon, Sep 8, 2014 at 2:22 PM, Lawrence Velázquez lar...@macports.org wrote: - My first assertion is that MacPorts' libstdc++ is broken on OS X because it doesn't use the system C++ runtime, libc++abi. This assertion, strictly speaking, is not about C++11 support. It strictly IS about C++11 support, because *that support defines the runtime ABI*. You have no options; if you insist on the system provided runtime, then either it provides the C++11 ABI or it does not, and that defines what level of C++ support you provide. That is precisely why this problem exists, and why it will continue to exist unless we provide viable support for other than the system's C++ runtime. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Supporting C++11 on old OS X (Was: kdevelop 4.7 and beyond (was: clang++-mp-3.4 doesn't find initializer_list on OS X 10.6))
On Mon, Sep 8, 2014 at 2:22 PM, Lawrence Velázquez lar...@macports.org wrote: - My first assertion is that MacPorts' libstdc++ is broken on OS X because it doesn't use the system C++ runtime, libc++abi. This assertion, strictly speaking, is not about C++11 support. It strictly IS about C++11 support, because *that support defines the runtime ABI*. You have no options; if you insist on the system provided runtime, then either it provides the C++11 ABI or it does not, and that defines what level of C++ support you provide. That is precisely why this problem exists, and why it will continue to exist unless we provide viable support for other than the system's C++ runtime. Okay, I wasn't aware of that. So if we start using our own libc++abi on older OS X, wouldn't C++ binaries built with Xcode's compilers be unable to interoperate with binaries built with MacPorts compilers? vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Supporting C++11 on old OS X (Was: kdevelop 4.7 and beyond (was: clang++-mp-3.4 doesn't find initializer_list on OS X 10.6))
On Mon, Sep 8, 2014 at 2:35 PM, Lawrence Velázquez lar...@macports.org wrote: So if we start using our own libc++abi on older OS X, wouldn't C++ binaries built with Xcode's compilers be unable to interoperate with binaries built with MacPorts compilers? Only if you try to use it for pre-C++11; but in that case we use the system's runtime. Short history lesson: Originally, C++ did not have a formal runtime ABI/API; the C++ standard specifically said that it was compiler specific. As a result, C++ compilers generally did not interoperate at all. C++11 recognized that this was a problem and formalized the API. All C++11 compatible compilers use the same runtime API and can interoperate. libstdc++ vs. libc++ tends to be a proxy for this conflict on OS X, because Apple had been shipping the last GPL2-licensed libstdc++, which did not have C++11's API. Apple won't ship GPL3, so they won't update libstdc++ to support C++11; instead they started shipping libc++, which supports C++11 and is not GPL3. But the fundamental problem is not libc++ vs. libstdc++; if you are not hampered by GPL3 (as on Linux), you can use a modern libstdc++ interchangeably with libc++. 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. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Supporting C++11 on old OS X (Was: kdevelop 4.7 and beyond (was: clang++-mp-3.4 doesn't find initializer_list on OS X 10.6))
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, xmonadhttp://sinenomine.net ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
