#40231: mkvtoolnix: fix build with clang ---------------------------+-------------------------------- Reporter: ryandesign@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Resolution: | Keywords: Port: mkvtoolnix | ---------------------------+-------------------------------- Comment (by jeremyhu@…): Replying to [comment:16 ecronin@…]:
Replying to [comment:14 jeremyhu@…]:
Replying to [comment:12 ecronin@…]:
except maybe ditching the system compilers completely and using a newer FSF g++ for all of macports.
NO! That will not be done. We will not be going to FSF for compilers. The goal is to use the host C++ runtime, not a conflicting one.
I only meant on PPC where clang isn't viable. There's no good option there, but most macports software probably doesn't touch C++ system- provided libraries, so as long as everything in macports uses new libstdc++ and gcc it should be internally consistent.
Yes, until clang has much better support for darwin/ppc, the only viable C++11 option for darwin/ppc is from gcc. That unfortunately presents a problem as macports-gcc-X.Y cannot be used for most +universal builds, so you'd be pinning yourself into -universal (but hopefully that is OK). I suggest trying to set configure.compiler to macports-gcc-4.8 in macports.conf and seeing what breaks. Given how ignored ppc is at this point in general, you may be in for a ride, but please do provide patches.
Software that depends on OS X frameworks and would have conflicting runtimes probably doesn't work on something that old to begin with, but more general cross-platform software could probably still work with newer compilers than gcc4.0 and gcc4.2. I know you'd like to axe everything older than Lion but there are still a lot of people with PPCs out there and macports is one of the few options for them. I don't know if there's anybody unofficially maintaining the older PPC OSs in base, this would be something for them to look into not you...
I'm not suggesting axing everything older than Lion. I've never said that, so please don't misunderstand me. I think that SL is an amazing OS, and there are plenty of reasons that people can't or won't update to a newer OS. To be honest, I think we may eventually face the question of whether or not to drop support for Lion while keeping support for SL, and I think we may need to eventually roll up a modern toolchain package for SL users to help them bootstrap. Such a package would likely contain the ld64, cctools, clang-3.3, libc++, and libc++abi ports.
If *everything* is using libc++, we will have issues when using the host C++ frameworks that are using libstdc++, but I don't think any of our ports actually do that.
Accelerate.framework is linked against libstdc++ on Lion at least, and I know there are ports that use it.
Yes, Accelerate.framework links against a C++ runtime, but it doesn't expose any C++ APIs that I'm aware of, so that's ok. The issue is that if you have a C++ API usage that crosses images, both sides of that boundary need to be using the same runtime. You can have a portion of your process using libstdc++ and another portion using libc++ just as long as they don't try to share objects. -- Ticket URL: <https://trac.macports.org/ticket/40231#comment:17> MacPorts <http://www.macports.org/> Ports system for OS X