[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:4 ecronin@…]:
 > If a compiler even knows about -std=c++11 it will be the same as
 -std=c++0x for it as far as I know, c++0x was just the name before they
 knew what year it would finally be ratified and when they came up with the
 final name 0x became an alias for it.

 Right, but by extension then, if a compiler user -std=c++0x, that probably
 means it doesn't support the full standard because the compiler came out
 when the standard was still a draft.  Of course, just because a compiler
 knows about -std=c++11 doesn't mean it implements everything, so yeah...
 my reasoning goes out the window.

 > http://clang.llvm.org/cxx_status.html lists what version of clang
 various c++0x/c++11 features were first added, I wouldn't be surprised if
 XCode's clang/libc++ is too old to support everything mkvtoolnix uses, but
 I'd think the latest clang and latest libc++ out of ports would since
 Clang has full C++11 support now.

 libc++ is shipped with the OS, not with XCode.

 The "llvm version" of clang is reported along with the "Apple Marketing
 version" of clang when you run 'clang --version' ... with currently
 released versions of Xcode's Command Line Tools, you should see '(based on
 LLVM 3.2svn)'.

 As Ryan mentioned above, the issue is with the STL being used, not with
 the compiler being used.  By default on Mountain Lion, the gcc-4.2 STL is
 used, and IT doesn't support some of the required features.

 > But since boost was compiled with the defaults (clang 3.2 and
 gcc4.2-like libstdc++) I think there's still going to be trouble using it
 when compiling the app with clang 3.4 libc++.

 Yes, symbol mangling and other incompatibilities abound if you try to mix
 them.

 > See e.g. #38374.  Boost itself was also compiles without -std=c++11, I
 don't know if this makes as big a difference as the older compiler and
 much older stdlib features.

 Yep.

 > I really think embedded static boost builds like suggested in the ticket
 you abandoned for this one (#34806) may be the best way to handle this.
 Boost is big and complex and really wants to be used with the exact same
 stdlib/language features as it was compiled with in my experience, and
 there's no one-size-fits-all boost for MacPorts that can do that.

 Yep, as I mentioned in #34806, one of the ways to solve this issue for <
 Mavericks is to use the static libs from boost and icu with the MacPorts
 libgcc runtime.

 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++.

-- 
Ticket URL: <https://trac.macports.org/ticket/40231#comment:7>
MacPorts <http://www.macports.org/>
Ports system for OS X