[MacPorts] #40231: mkvtoolnix: fix build with clang

[MacPorts]

#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