mkvtoolnix 5.1.0: special requirements

[Ryan Schmidt]

On Nov 30, 2011, at 01:49, KonaBlend wrote:

> Upstream mkvtoolnix 5.1.0 has introduced a requirement for various c++11 features which at this time are available via gcc 4.6 or higher. clang top-of-trunk is not yet there; specifically initializer lists and lambda support are absent. Also note since the upstream author does not use OSX, it's very likely that as clang catches up on these features, mkvtoolnix will expand its c++11 feature usage dictated by gcc.
> 
> Given the undefined (unreliable and risky) nature of mixing 3rd-party c++, standard c++, and low-level c++ runtime libraries, going forward the safest way to build this port is to guarantee a consistent compiler and standard c++ library is used for building:
> 
> a. mkvtoolnix
> b. libboost*.dylib
> c. libstdc++.dylib
> d. libgcc_s.dylib
> 
> Here is an outline to a solution I'm thinking of:
> 
> 1. new port:mkvtoolnix-gcc46 and install to mkvtoolnix private subtree.
> 2. new port:mkvtoolnix-boost and install to mkvtoolnix private subtree.
> 3. modify port:mkvtoolnix to depend on port:mkvtoolnix-gcc46 and port:mkvtoolnix-boost and install to mkvtoolnix private subtree.
> 4. make mkv executables available to /opt/local/bin via symlinks
> 
> This solution, while duping gcc46 and boost, does continue to significantly benefit from and use the macports tree to the tune of at least 15 other dynamic libraries. In the future as mkvtoolnix requirements become aligned with the general shared macports tree, things can be simplified again.
> 
> Thoughts?

Ugh. It sounds ugly.

Can the clang-3.0/clang-3.1 ports help at all? If one of those would work for building mkvtoolnix I'd rather use those than gcc46, given all the problems gcc46 has had and still has (see issue tracker) and the fact that the future of OS X is based on clang, not gcc.

Another option would be to not update mkvtoolnix, until it returns to programming practices that are compatible with compilers in Xcode.