#44168: mkvtoolnix 7.0 crash on start -------------------------+------------------------------------------ Reporter: bunk3m@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: MacPorts 2.3.1 Component: ports | Version: 2.3.1 Resolution: | Keywords: mkvtoolnix, video, wxwidgets Port: mkvtoolnix | -------------------------+------------------------------------------ Comment (by bunk3m@…): Forgot to mention that I'm using OSX 10.8.5. -- Ticket URL: <https://trac.macports.org/ticket/44168#comment:1> MacPorts <http://www.macports.org/> Ports system for OS X

#44168: mkvtoolnix 7.0 crash on start -------------------------+-------------------------------- Reporter: bunk3m@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.1 Resolution: | Keywords: Port: mkvtoolnix | -------------------------+-------------------------------- Comment (by ryandesign@…): Right, the answer is to upgrade to Mavericks. -- Ticket URL: <https://trac.macports.org/ticket/44168#comment:3> MacPorts <http://www.macports.org/> Ports system for OS X

#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

#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@…): That would be perfect. Are you willing to make that change? (I don't even know the core well enough.) -- Ticket URL: <https://trac.macports.org/ticket/44168#comment:7> MacPorts <http://www.macports.org/> Ports system for OS X