[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:16 ecronin@…]:
 > Replying to [comment:14 jeremyhu@…]:
 > > Replying to [comment:12 ecronin@…]:
 > >
 > > > except maybe ditching the system compilers completely and using a
 newer FSF g++ for all of macports.
 > >
 > > NO!  That will not be done.  We will not be going to FSF for
 compilers.  The goal is to use the host C++ runtime, not a conflicting
 one.
 > >
 >
 > I only meant on PPC where clang isn't viable.  There's no good option
 there, but most macports software probably doesn't touch C++ system-
 provided libraries, so as long as everything in macports uses new
 libstdc++ and gcc it should be internally consistent.

 Yes, until clang has much better support for darwin/ppc, the only viable
 C++11 option for darwin/ppc is from gcc.  That unfortunately presents a
 problem as macports-gcc-X.Y cannot be used for most +universal builds, so
 you'd be pinning yourself into -universal (but hopefully that is OK).

 I suggest trying to set configure.compiler to macports-gcc-4.8 in
 macports.conf and seeing what breaks.  Given how ignored ppc is at this
 point in general, you may be in for a ride, but please do provide patches.

 > Software that depends on OS X frameworks and would have conflicting
 runtimes probably doesn't work on something that old to begin with, but
 more general cross-platform software could probably still work with newer
 compilers than gcc4.0 and gcc4.2.  I know you'd like to axe everything
 older than Lion but there are still a lot of people with PPCs out there
 and macports is one of the few options for them.  I don't know if there's
 anybody unofficially maintaining the older PPC OSs in base, this would be
 something for them to look into not you...

 I'm not suggesting axing everything older than Lion.  I've never said
 that, so please don't misunderstand me.  I think that SL is an amazing OS,
 and there are plenty of reasons that people can't or won't update to a
 newer OS.  To be honest, I think we may eventually face the question of
 whether or not to drop support for Lion while keeping support for SL, and
 I think we may need to eventually roll up a modern toolchain package for
 SL users to help them bootstrap.  Such a package would likely contain the
 ld64, cctools, clang-3.3, libc++, and libc++abi ports.

 > > If *everything* is using libc++, we will have issues when using the
 host C++ frameworks that are using libstdc++, but I don't think any of our
 ports actually do that.
 >
 > Accelerate.framework is linked against libstdc++ on Lion at least, and I
 know there are ports that use it.

 Yes, Accelerate.framework links against a C++ runtime, but it doesn't
 expose any C++ APIs that I'm aware of, so that's ok.  The issue is that if
 you have a C++ API usage that crosses images, both sides of that boundary
 need to be using the same runtime.  You can have a portion of your process
 using libstdc++ and another portion using libc++ just as long as they
 don't try to share objects.

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