#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 ecronin@…): Replying to [comment:11 jeremyhu@…]:
Replying to [comment:9 ecronin@…]:
But then it blows up at link time with missing boost symbols.
Well that is expected because libc++ and libstdc++ have differnet symbol mangling.
Yep. I was thinking from the bits about libstdc++ compatibility on the llvm website that it was a bit better than that.
I'm rebuilding a modified boost now to see if that gets mkvtoolnix to complete.
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)
I'll upload my modified patches and the results when they get done.
Thanks. That should get this working on Mavericks at least...
Attached.
Replying to [comment:10 ecronin@…]:
Replying to [comment:7 jeremyhu@…]: Switching to always using clang/libc++ as the default compiler is probably worth exploring (I don't know if current xcode-dependent default C compiler and clang++ or clang/clang++ is better).
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. But Clang on PPC is still alpha/beta from my understanding, so I guess there's really no good fix for users stuck there, except maybe ditching the system compilers completely and using a newer FSF g++ for all of macports. I'm not sure how many system libs that would require linking in expose c++ APIs though, at which point that fails completely...
Boost is probably going to keep dropping support for those old versions, meaning no port that depends on it will work on those older OSs due to C++ runtime mixing (I didn't follow the thread on the most recent update closely, but it looks from the Portfile blacklist like boost might now be using a newer FSF gcc on some older OS X releases?
No. boost is using modern clang everywhere:
{{{ compiler.fallback-append macports-clang-3.3 # clang++ produces broken boost libraries (https://trac.macports.org/ticket/31525) # If Apple's clang is used on 32-bit systems, it seems to silently ignore the '-march=i386' flag. # (https://trac.macports.org/ticket/38157) # gcc <= 4.2 does not support TR1 result_of protocol # https://trac.macports.org/ticket/39809 compiler.blacklist {clang < 421} macports-clang-2.9 macports-clang-3.0 llvm-gcc-4.2 macports-llvm-gcc-4.2 apple-gcc-4.2 gcc-4.2 gcc-4.0 apple- gcc-4.0 gcc-3.3 }}}
I totally missed the fallback-append above the comment, just saw the blacklisting of every Apple compiler on XCode3 era OSs below it... 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 the -dev for discussion for people more knowledgeable 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? -- Ticket URL: <https://trac.macports.org/ticket/40231#comment:12> MacPorts <http://www.macports.org/> Ports system for OS X