#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:9 ecronin@…]:
I thought that some of the final missing C++11 features with clang/libc++ were in parts of the standard that involved the stdlib, but that doesn't appear to be the case... From what I can tell, the version of libc++ that shipped with 10.7 claims to fully implement the new standard (there aren't any version numbers or changelogs for it though, so it's hard to be certain. The svn you pull today definitely claims full support, but it's not clear what Lion came with. The internal version number in !__config is the same for both, so I'm taking that to mean nothing major like adding c++11 required features has changed).
Hmm... I'm surprised to see that libcxx isn't available on http://opensource.apple.com ... I wonder why that is...
Replying to [comment:5 ryandesign@…]:
See my patch. I tested all clangs I could and listed in
compiler.blacklist those that don't pass the configure script check. The remaining ones, including the very latest pre-release of clang 3.4, fail to build the port, as I described at the top of this ticket.
The error in the ticket description can be avoided by just commenting
out that chunk of code (it's in the built-in livecheck/selfupdate that we probably don't want enabled in a port to begin with), I didn't feel like trying to debug the error. Oh, nice.
There is another syntax later on that is easier to fix.
Can you provide that patch?
But then it blows up at link time with missing boost symbols.
Well that is expected because libc++ and libstdc++ have differnet symbol mangling.
I'm guessing this is because boost wasn't built using libc++ and/or c++11.
It has to do with the runtime, not the standard.
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).
I'll upload my modified patches and the results when they get done.
Thanks. That should get this working on Mavericks at least... Replying to [comment:10 ecronin@…]:
Replying to [comment:7 jeremyhu@…]:
The other alternative is to have a C++ Flag Day where we simultaneously revbump every C++ project that uses C++ across an API boundary to start using libc++ instead of libstdc++.
Continuing to use a gcc4.2 based libstdc++ (and ancient gcc's on pre- XCode4 OSs) is going to be a bigger and bigger issue for C++ code I think.
Yep.
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).
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 }}}
that can't be good...).
Well, it's not the case, so no worries there ;)
Boost is also particularly problematic as it is so tightly entangled with the particular compiler version and options used to compile it. I think the stdlib is the biggest issue, but I don't know for sure what gets built differently in the boost libraries when you compile with --std=c++11, and how that interacts with the template portions of boost that are compiled later in some program without using c++11...
Certainly the C++ standard used to build boost determines what features it uses and provides. -- Ticket URL: <https://trac.macports.org/ticket/40231#comment:11> MacPorts <http://www.macports.org/> Ports system for OS X