mkvtoolnix: fix build with clang

[ryandesign (Ryan Carsten Schmidt)]

mkvtoolnix currently requires gcc 4.6 or newer to build, but mkvextract crashes because boost and icu have not been built with the same compiler. The idea of getting new ports of boost and icu built with such a compiler is explored in #34806.

In this ticket, I'd instead like to explore the idea of getting mkvtoolnix to build correctly with clang. In r109693 Jeremy H.S. disabled the port on Mavericks adding a comment saying this would be the necessary fix.

Attached is a patch that begins work toward this solution.

The configure script tests for various C++11 features that are required, but it doesn't find three of them even in versions of clang that have them because -stdlib=libc++ was not used. I added a patch to add this to the configure script. However it must only be added when the compiler is clang. When the compiler is gcc 4.6 or newer, adding this flag causes all the C++11 feature tests to fail.

Unfortunately even with recent clang the build eventually fails:

With clang version "Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)" from Xcode 4.6.2, the error is:

/usr/bin/../lib/c++/v1/vector:1822:21: fatal error: overload resolution selected implicitly-deleted copy assignment operator
                __m = __first;
                    ^

With MacPorts clang 3.3 and 3.4, the error wording is slightly different:

/opt/local/libexec/llvm-3.3/bin/../lib/c++/v1/vector:1879:21: fatal error: object of type 'boost::filter_iterator<<lambda at src/common/command_line.cpp:295:74>, boost::transform_iterator<boost::range_detail::select_first<std::__1::map<std::__1::basic_string<char>, std::__1::basic_string<char>, std::__1::less<std::__1::basic_string<char> >, std::__1::allocator<std::__1::pair<const std::__1::basic_string<char>, std::__1::basic_string<char> > > > >, std::__1::__map_const_iterator<std::__1::__tree_const_iterator<std::__1::pair<std::__1::basic_string<char>, std::__1::basic_string<char> >, const std::__1::__tree_node<std::__1::pair<std::__1::basic_string<char>, std::__1::basic_string<char> >, void *> *, long> >, boost::use_default, boost::use_default> >' cannot be assigned because its copy assignment operator is implicitly deleted
                __m = __first;
                    ^

[mojca (Mojca Miklavec)]

Cc Me!

[cooljeanius (Eric Gallager)]

Cc Me!

[jeremyhu (Jeremy Huddleston Sequoia)]

Well that's part of the problem...

They are setting -stc=c++0x and expecting to find c++11 features.

If they want C++11, they need to specify -std=c++11

--Jeremy

[ecronin (Eric Cronin)]

If a compiler even knows about -std=c++11 it will be the same as -std=c++0x for it as far as I know, c++0x was just the name before they knew what year it would finally be ratified and when they came up with the final name 0x became an alias for it. ​http://clang.llvm.org/cxx_status.html lists what version of clang various c++0x/c++11 features were first added, I wouldn't be surprised if XCode's clang/libc++ is too old to support everything mkvtoolnix uses, but I'd think the latest clang and latest libc++ out of ports would since Clang has full C++11 support now.

But since boost was compiled with the defaults (clang 3.2 and gcc4.2-like libstdc++) I think there's still going to be trouble using it when compiling the app with clang 3.4 libc++. See e.g. #38374. Boost itself was also compiles without -std=c++11, I don't know if this makes as big a difference as the older compiler and much older stdlib features.

I really think embedded static boost builds like suggested in the ticket you abandoned for this one (#34806) may be the best way to handle this. Boost is big and complex and really wants to be used with the exact same stdlib/language features as it was compiled with in my experience, and there's no one-size-fits-all boost for MacPorts that can do that.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ecronin@…:

​http://clang.llvm.org/cxx_status.html lists what version of clang various c++0x/c++11 features were first added,

Yes, that was brought to my attention on the mailing list, which prompted my further investigation, which led to this ticket.

I wouldn't be surprised if XCode's clang/libc++ is too old to support everything mkvtoolnix uses, but I'd think the latest clang and latest libc++ out of ports would since Clang has full C++11 support now.

See my patch. I tested all clangs I could and listed in compiler.blacklist those that don't pass the configure script check. The remaining ones, including the very latest pre-release of clang 3.4, fail to build the port, as I described at the top of this ticket.

I did not test the libcxx port. It does not appear to be particularly recent.

But since boost was compiled with the defaults (clang 3.2 and gcc4.2-like libstdc++) I think there's still going to be trouble using it when compiling the app with clang 3.4 libc++. See e.g. #38374. Boost itself was also compiles without -std=c++11, I don't know if this makes as big a difference as the older compiler and much older stdlib features.

I have no idea how this stuff works or if that matters.

I really think embedded static boost builds like suggested in the ticket you abandoned for this one (#34806) may be the best way to handle this. Boost is big and complex and really wants to be used with the exact same stdlib/language features as it was compiled with in my experience, and there's no one-size-fits-all boost for MacPorts that can do that.

If you think that's the answer, re-open #34806 and come to an agreement with Jeremy H.S., who said there that that won't work but didn't elaborate.

[ryandesign (Ryan Carsten Schmidt)]

Eric, please see my remarks in the ticket; I didn't realize you weren't Cc'd yet.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to ecronin@…:

If a compiler even knows about -std=c++11 it will be the same as -std=c++0x for it as far as I know, c++0x was just the name before they knew what year it would finally be ratified and when they came up with the final name 0x became an alias for it.

Right, but by extension then, if a compiler user -std=c++0x, that probably means it doesn't support the full standard because the compiler came out when the standard was still a draft. Of course, just because a compiler knows about -std=c++11 doesn't mean it implements everything, so yeah... my reasoning goes out the window.

​http://clang.llvm.org/cxx_status.html lists what version of clang various c++0x/c++11 features were first added, I wouldn't be surprised if XCode's clang/libc++ is too old to support everything mkvtoolnix uses, but I'd think the latest clang and latest libc++ out of ports would since Clang has full C++11 support now.

libc++ is shipped with the OS, not with XCode.

The "llvm version" of clang is reported along with the "Apple Marketing version" of clang when you run 'clang --version' ... with currently released versions of Xcode's Command Line Tools, you should see '(based on LLVM 3.2svn)'.

As Ryan mentioned above, the issue is with the STL being used, not with the compiler being used. By default on Mountain Lion, the gcc-4.2 STL is used, and IT doesn't support some of the required features.

But since boost was compiled with the defaults (clang 3.2 and gcc4.2-like libstdc++) I think there's still going to be trouble using it when compiling the app with clang 3.4 libc++.

Yes, symbol mangling and other incompatibilities abound if you try to mix them.

See e.g. #38374. Boost itself was also compiles without -std=c++11, I don't know if this makes as big a difference as the older compiler and much older stdlib features.

Yep.

I really think embedded static boost builds like suggested in the ticket you abandoned for this one (#34806) may be the best way to handle this. Boost is big and complex and really wants to be used with the exact same stdlib/language features as it was compiled with in my experience, and there's no one-size-fits-all boost for MacPorts that can do that.

Yep, as I mentioned in #34806, one of the ways to solve this issue for < Mavericks is to use the static libs from boost and icu with the MacPorts libgcc runtime.

The other alternative is to have a C++ Flag Day where we simultaneously revbump every C++ project that uses C++ across an API boundary to start using libc++ instead of libstdc++.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to ryandesign@…:

See my patch. I tested all clangs I could and listed in compiler.blacklist those that don't pass the configure script check. The remaining ones, including the very latest pre-release of clang 3.4, fail to build the port, as I described at the top of this ticket.

Yes, that is the build failure that prompted my comment in the Port. I'm not really a C++ language guru, so I'm not sure how to fix that bug.

I did not test the libcxx port. It does not appear to be particularly recent.

That just provides the runtime for Snow Leopard. I don't plan on changing it (except maybe to bump the compiler used to 3.3 (so as to not force multiple clang installs)

I really think embedded static boost builds like suggested in the ticket you abandoned for this one (#34806) may be the best way to handle this. Boost is big and complex and really wants to be used with the exact same stdlib/language features as it was compiled with in my experience, and there's no one-size-fits-all boost for MacPorts that can do that.

If you think that's the answer, re-open #34806 and come to an agreement with Jeremy H.S., who said there that that won't work but didn't elaborate.

I was saying that simply updating to newer gcc wouldn't work. The issue is the mixing of C++ runtimes.

[ecronin (Eric Cronin)]

Replying to jeremyhu@…:

Replying to ryandesign@…:

See my patch. I tested all clangs I could and listed in compiler.blacklist those that don't pass the configure script check. The remaining ones, including the very latest pre-release of clang 3.4, fail to build the port, as I described at the top of this ticket.

Yes, that is the build failure that prompted my comment in the Port. I'm not really a C++ language guru, so I'm not sure how to fix that bug.

I did not test the libcxx port. It does not appear to be particularly recent.

That just provides the runtime for Snow Leopard. I don't plan on changing it (except maybe to bump the compiler used to 3.3 (so as to not force multiple clang installs)

I thought that some of the final missing C++11 features with clang/libc++ were in parts of the standard that involved the stdlib, but that doesn't appear to be the case... From what I can tell, the version of libc++ that shipped with 10.7 claims to fully implement the new standard (there aren't any version numbers or changelogs for it though, so it's hard to be certain. The svn you pull today definitely claims full support, but it's not clear what Lion came with. The internal version number in __config is the same for both, so I'm taking that to mean nothing major like adding c++11 required features has changed).

Replying to ryandesign@…:

See my patch. I tested all clangs I could and listed in compiler.blacklist those that don't pass the configure script check. The remaining ones, including the very latest pre-release of clang 3.4, fail to build the port, as I described at the top of this ticket.

The error in the ticket description can be avoided by just commenting out that chunk of code (it's in the built-in livecheck/selfupdate that we probably don't want enabled in a port to begin with), I didn't feel like trying to debug the error. There is another syntax later on that is easier to fix. But then it blows up at link time with missing boost symbols. I'm guessing this is because boost wasn't built using libc++ and/or c++11. I'm rebuilding a modified boost now to see if that gets mkvtoolnix to complete. I'll upload my modified patches and the results when they get done.

[ecronin (Eric Cronin)]

Replying to jeremyhu@…:

The other alternative is to have a C++ Flag Day where we simultaneously revbump every C++ project that uses C++ across an API boundary to start using libc++ instead of libstdc++.

Continuing to use a gcc4.2 based libstdc++ (and ancient gcc's on pre-XCode4 OSs) is going to be a bigger and bigger issue for C++ code I think. Switching to always using clang/libc++ as the default compiler is probably worth exploring (I don't know if current xcode-dependent default C compiler and clang++ or clang/clang++ is better). Boost is probably going to keep dropping support for those old versions, meaning no port that depends on it will work on those older OSs due to C++ runtime mixing (I didn't follow the thread on the most recent update closely, but it looks from the Portfile blacklist like boost might now be using a newer FSF gcc on some older OS X releases? that can't be good...). Boost is also particularly problematic as it is so tightly entangled with the particular compiler version and options used to compile it. I think the stdlib is the biggest issue, but I don't know for sure what gets built differently in the boost libraries when you compile with --std=c++11, and how that interacts with the template portions of boost that are compiled later in some program without using c++11...

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to ecronin@…:

I thought that some of the final missing C++11 features with clang/libc++ were in parts of the standard that involved the stdlib, but that doesn't appear to be the case... From what I can tell, the version of libc++ that shipped with 10.7 claims to fully implement the new standard (there aren't any version numbers or changelogs for it though, so it's hard to be certain. The svn you pull today definitely claims full support, but it's not clear what Lion came with. The internal version number in __config is the same for both, so I'm taking that to mean nothing major like adding c++11 required features has changed).

Hmm... I'm surprised to see that libcxx isn't available on ​http://opensource.apple.com ... I wonder why that is...

Replying to ryandesign@…:

See my patch. I tested all clangs I could and listed in compiler.blacklist those that don't pass the configure script check. The remaining ones, including the very latest pre-release of clang 3.4, fail to build the port, as I described at the top of this ticket.

The error in the ticket description can be avoided by just commenting out that chunk of code (it's in the built-in livecheck/selfupdate that we probably don't want enabled in a port to begin with), I didn't feel like trying to debug the error.

Oh, nice.

There is another syntax later on that is easier to fix.

Can you provide that patch?

But then it blows up at link time with missing boost symbols.

Well that is expected because libc++ and libstdc++ have differnet symbol mangling.

I'm guessing this is because boost wasn't built using libc++ and/or c++11.

It has to do with the runtime, not the standard.

I'm rebuilding a modified boost now to see if that gets mkvtoolnix to complete.

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).

I'll upload my modified patches and the results when they get done.

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

Replying to ecronin@…:

Replying to jeremyhu@…:

The other alternative is to have a C++ Flag Day where we simultaneously revbump every C++ project that uses C++ across an API boundary to start using libc++ instead of libstdc++.

Continuing to use a gcc4.2 based libstdc++ (and ancient gcc's on pre-XCode4 OSs) is going to be a bigger and bigger issue for C++ code I think.

Yep.

Switching to always using clang/libc++ as the default compiler is probably worth exploring (I don't know if current xcode-dependent default C compiler and clang++ or clang/clang++ is better).

clang is the default C compiler with current XCode (which is version 4.6.x on Lion and ML).

Boost is probably going to keep dropping support for those old versions, meaning no port that depends on it will work on those older OSs due to C++ runtime mixing (I didn't follow the thread on the most recent update closely, but it looks from the Portfile blacklist like boost might now be using a newer FSF gcc on some older OS X releases?

No. boost is using modern clang everywhere:

compiler.fallback-append macports-clang-3.3
# clang++ produces broken boost libraries (https://trac.macports.org/ticket/31525)
# If Apple's clang is used on 32-bit systems, it seems to silently ignore the '-march=i386' flag.
# (https://trac.macports.org/ticket/38157)
# gcc <= 4.2 does not support TR1 result_of protocol
# https://trac.macports.org/ticket/39809
compiler.blacklist {clang < 421} macports-clang-2.9 macports-clang-3.0 llvm-gcc-4.2 macports-llvm-gcc-4.2 apple-gcc-4.2 gcc-4.2 gcc-4.0 apple-gcc-4.0 gcc-3.3

that can't be good...).

Well, it's not the case, so no worries there ;)

Boost is also particularly problematic as it is so tightly entangled with the particular compiler version and options used to compile it. I think the stdlib is the biggest issue, but I don't know for sure what gets built differently in the boost libraries when you compile with --std=c++11, and how that interacts with the template portions of boost that are compiled later in some program without using c++11...

Certainly the C++ standard used to build boost determines what features it uses and provides.

[ecronin (Eric Cronin)]

Replying to jeremyhu@…:

Replying to ecronin@…:

But then it blows up at link time with missing boost symbols.

Well that is expected because libc++ and libstdc++ have differnet symbol mangling.

Yep. I was thinking from the bits about libstdc++ compatibility on the llvm website that it was a bit better than that.

I'm rebuilding a modified boost now to see if that gets mkvtoolnix to complete.

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)

I'll upload my modified patches and the results when they get done.

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

Attached.

Replying to ecronin@…:

Replying to jeremyhu@…: Switching to always using clang/libc++ as the default compiler is probably worth exploring (I don't know if current xcode-dependent default C compiler and clang++ or clang/clang++ is better).

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. But Clang on PPC is still alpha/beta from my understanding, so I guess there's really no good fix for users stuck there, except maybe ditching the system compilers completely and using a newer FSF g++ for all of macports. I'm not sure how many system libs that would require linking in expose c++ APIs though, at which point that fails completely...

Boost is probably going to keep dropping support for those old versions, meaning no port that depends on it will work on those older OSs due to C++ runtime mixing (I didn't follow the thread on the most recent update closely, but it looks from the Portfile blacklist like boost might now be using a newer FSF gcc on some older OS X releases?

No. boost is using modern clang everywhere:

compiler.fallback-append macports-clang-3.3
# clang++ produces broken boost libraries (https://trac.macports.org/ticket/31525)
# If Apple's clang is used on 32-bit systems, it seems to silently ignore the '-march=i386' flag.
# (https://trac.macports.org/ticket/38157)
# gcc <= 4.2 does not support TR1 result_of protocol
# https://trac.macports.org/ticket/39809
compiler.blacklist {clang < 421} macports-clang-2.9 macports-clang-3.0 llvm-gcc-4.2 macports-llvm-gcc-4.2 apple-gcc-4.2 gcc-4.2 gcc-4.0 apple-gcc-4.0 gcc-3.3

I totally missed the fallback-append above the comment, just saw the blacklisting of every Apple compiler on XCode3 era OSs below it...

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?

[ecronin (Eric Cronin)]

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

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to 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 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.

[jeremyhu (Jeremy Huddleston Sequoia)]

r110028 gets it working on Mavericks

[ecronin (Eric Cronin)]

Replying to jeremyhu@…:

Replying to 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. 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...

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.

Accelerate.framework is linked against libstdc++ on Lion at least, and I know there are ports that use it.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to ecronin@…:

Replying to jeremyhu@…:

Replying to 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.

[mojca (Mojca Miklavec)]

See also #43222.

[mopihopi]

Cc Me!

[mojca (Mojca Miklavec)]

Can someone please explain me the error from the description? It looks as if the error occurs before even compiling any line code, already during inclusion of headers. As if the system headers confuse type definitions from boost with their own.

[pixilla (Bradley Giesbrecht)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Replying to jeremyhu@…:

r110028 gets it working on Mavericks

I have reported the issue in src/common/command_line.cpp to the developers in ​https://github.com/mbunkus/mkvtoolnix/issues/1175 so they can hopefully develop a better fix that doesn't involve just commenting out a whole block of code. I have reported the issue in src/common/version.cpp and the fix you used in ​https://github.com/mbunkus/mkvtoolnix/issues/1176.

[ryandesign (Ryan Carsten Schmidt)]

Fixes for the clang build failures were committed upstream and released in 7.9.0 to which the port was updated in r136337; it now builds with clang with no patches.