[MacPorts] #44168: mkvtoolnix 7.0 crash on start

[MacPorts]

#44168: mkvtoolnix 7.0 crash on start
-------------------------+--------------------------------
  Reporter:  bunk3m@…    |      Owner:  macports-tickets@…
      Type:  defect      |     Status:  new
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:
Resolution:              |   Keywords:
      Port:  mkvtoolnix  |
-------------------------+--------------------------------

Comment (by mojca@…):

 I referenced the other ticket in the description. This ticket is a
 duplicate, but I will try to explain a bit more in detail.

 The easiest solution for this is probably to fetch the binary from the
 site they link to. I tried it and it seems to work (I didn't experiment a
 lot, but at least it started).

 The other doable workaround is to install '''the complete''' MacPorts with
 `libc++`. I tried it a few days ago and `mkvtoolnix` works. Jeremy also
 says that he has all of his machines running on `libc++` without any major
 issues. And that he's not willing to spend time patching things for
 `libstdc++`. I would actually like to suggest that MacPorts should
 '''really''' start supporting that setup officially. If it doesn't, it
 will pretty soon become useless on < 10.9. And that probably doesn't even
 mean unmanageable manpower. After Jeremy did the initial patching and
 after the release of 2.3.0 many things simply work out-of-the-box. And I
 would be willing to invest time into patching things. Some other people
 probably as well. The prerequisite though (chicken-and-egg problem) would
 be to set up two additional buildbots to provide binary packages. I'm
 willing to spend extra time providing patches, but I'm not wiling to
 compile the whole TeX Live, Qt, clang, root etc. after every single
 revbump. Last time I tried root compiled for 4 hours. But if we wait for
 too long, we'll miss the train. I that won't be done in the following few
 months, I will probably upgrade from 10.7 to 10.10 and I won't be willing
 to spend time patching the old stuff. And many other users will upgrade as
 well, sooner or later, so the pool of those willing to help will keep
 shrinking way below the critical mass. If we don't do that now, it will
 make less and less sense and macports users on < 10.9 will be more and
 more stuck with the old stuff. And before we realize we'll be bitten by
 C++14 and C++17 incompatibilities on 10.9 anyway ;).

 `wxWidgets` is only partially a problem. I recently changed mkvtoolnix to
 build against `wxWidgets` by default, but one can still install the port
 with `-wxwidgets`. (Anyway, if we fix boost and icu (in the sense of
 building the second and/or third copy with a different compiler), we might
 just as well fix wxWidgets since other ports like `FileZilla` have exactly
 the same problem; with the exception that `FileZilla` doesn't work without
 wx.)

 The ticket #34806 even provides a patch with a workaround to build a
 "private" version of boost and icu with a different compiler. But if we do
 that it would make more sense to ship something like `boost.gcc`,
 `icu.gcc`, `wxWidgets-3.0.gcc` and/or `boost.libcxx`, `icu.libcxx`,
 `wxWidgets-3.0.libcxx` rather than `mkvtoolnix.boost`. Then at least these
 ports could be reused as dependencies of other ports, not just
 `mkvtoolnix`.

 Creating three new ports seems simple enough, but we don't have any
 guidelines how to do that, where to put files etc. If we decide to go that
 route it would probably make sense to decide for some guidelines and then
 create a portgroup that would automatically change to
 `--prefix=${prefix}/something/libc++/` and add
 `${prefix}/something/libc++/include` to `CPPFLAGS`,
 `${prefix}/something/libc++/libs` to `LDFLAGS` etc.

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