[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 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