mkvtoolnix 7.0 crash on start

[bunk3m (Bunk3m)]

I did an update & upgrade today. As part of that v7.0.0 was installed/updated.

I tried to run but it crashes on start.

/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_baseu-3.0.dylib
*** error for object 0x7fff7c8e5ef0: pointer being freed was not allocated

Full crash report is attached.

See also ticket #34806.

[bunk3m (Bunk3m)]

Crash log

[bunk3m (Bunk3m)]

Forgot to mention that I'm using OSX 10.8.5.

[neverpanic (Clemens Lang)]

Please don't set the Milestone field for port bugs.

That's a C++ runtime library incompatibility. It probably happens because mkvtoolnix needs C++11, which is only possible with libc++, but wxWidgets is linked against the older and incompatible libstdc++. You then end up with two C++ runtimes in a single address space. Passing objects back and forth between those causes this crash.

Solution: Find a way to make C++11 work on systems earlier than Mavericks reliably. This is a global problem, and I'm afraid the answer to the problem might well be "it doesn't work, or at least we don't have the manpower to pull it off". I've CC'd mojca, who was been recently trying to make mkvtoolnix work on systems earlier than Mavericks.

[ryandesign (Ryan Carsten Schmidt)]

Right, the answer is to upgrade to Mavericks.

[mojca (Mojca Miklavec)]

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 official website (actually from the link on the official website; there are no official mac binaries). 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.

[ryandesign (Ryan Carsten Schmidt)]

Replying to mojca@…:

The prerequisite though (chicken-and-egg problem) would be to set up two additional buildbots to provide binary packages.

And the prereq for that is to put the C++ library name into the binary package name. In order to not force the buildbot to rebuild every package ever when we do that, we may want to add the C++ library name to the package name only when it differs from the OS default.

[mojca (Mojca Miklavec)]

That would be perfect. Are you willing to make that change? (I don't even know the core well enough.)

[mojca (Mojca Miklavec)]

What flag/name would be given to the port where the global MacPorts setting is libstdc++, but the port is compiled with libc++?

[ryandesign (Ryan Carsten Schmidt)]

I don't know. We can discuss that on the macports-dev mailing list if desired. This ticket is a duplicate of #34806.