#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:12 ecronin@…]:
You'll need to rebuild icu as well (and anything else that uses boost or icu ... this is a can of worms (see my comment above about a flag day being required to do something like this).
Yeah. Anything C++ actually. It doesn't even make it out of configure when you pass the -stdlib flags all the time (Ryan's patch was incomplete. cxxflags and ldflags seem to do the trick, on Mavericks you should know for sure)
Yeah, you need to ensure that both sides of the API use the same STL and runtime. The easiest way to do that is to just pick one and use it everywhere.
Thanks. That should get this working on Mavericks at least...
Attached.
Thanks. I'll massage what is safe to do now into a commit soon.
Replying to [comment:10 ecronin@…]: clang is the default C compiler with current XCode (which is version 4.6.x on Lion and ML).
I was thinking the still-unofficially-supported-OS-versions where no XCode4 is available.
That boundary is not quite clear. In my mind, the OS versions that are must not break are >= 10.7 ... I do my best to keep 10.6 working (and test on it). Anything older than that is just a battle with entropy. Also, clang-3.3 works great for i386 and x86_64 on Leopard and Snow Leopard (which don't support Xcode 4.6.x).
But Clang on PPC is still alpha/beta from my understanding, so I guess there's really no good fix for users stuck there,
I would urge dropping Tiger and powerpc as even legacy support (it's been almost a decade now) and use clang++ / libc++ on all supported platforms.
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'm not sure how many system libs that would require linking in expose c++ APIs though, at which point that fails completely...
There are a few C++ frameworks that won't work if you do that, but we're certainly not going to explore the option of using gcc as the toolchain. It is not supported by Apple and there are many cases where it outright fails (eg: If we want to use ObjC++ with host frameworks)
This was just an excuse to play around with the latest clang a bit, I'm throwing in the towel on any further attempts. Switching to libc++ is probably worth sending over to the -dev list for discussion for people more knowledgeable than me on OS X C++ development. Won't that have the same incompatible mangling/runtime problems with linking in any required system frameworks on pre-Mavericks OSs we're having here, though?
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.
Also, didn't report either of those compilation errors/fixes upstream... figured should wait until it builds and can be tested first.
I'll give it a whirl. Thanks. -- Ticket URL: <https://trac.macports.org/ticket/40231#comment:14> MacPorts <http://www.macports.org/> Ports system for OS X