[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:12 ecronin@…]:
 > > 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)

 Yeah, you need to ensure that both sides of the API use the same STL and
 runtime.  The easiest way to do that is to just pick one and use it
 everywhere.

 > > Thanks.  That should get this working on Mavericks at least...
 >
 > Attached.

 Thanks.  I'll massage what is safe to do now into a commit soon.

 > > Replying to [comment:10 ecronin@…]:
 > > 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.

 That boundary is not quite clear.  In my mind, the OS versions that are
 must not break are >= 10.7 ... I do my best to keep 10.6 working (and test
 on it).  Anything older than that is just a battle with entropy.

 Also, clang-3.3 works great for i386 and x86_64 on Leopard and Snow
 Leopard (which don't support Xcode 4.6.x).

 > But Clang on PPC is still alpha/beta from my understanding, so I guess
 there's really no good fix for users stuck there,

 I would urge dropping Tiger and powerpc as even legacy support (it's been
 almost a decade now) and use clang++ / libc++ on all supported platforms.

 > 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'm not sure how many system libs that would require linking in expose
 c++ APIs though, at which point that fails completely...

 There are a few C++ frameworks that won't work if you do that, but we're
 certainly not going to explore the option of using gcc as the toolchain.
 It is not supported by Apple and there are many cases where it outright
 fails (eg: If we want to use ObjC++ with host frameworks)

 > 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 to the -dev list for discussion for people
 more knowledgeable than me 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?

 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.

 > Also, didn't report either of those compilation errors/fixes upstream...
 figured should wait until it builds and can be tested first.

 I'll give it a whirl.  Thanks.

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