Am 01.12.2011 um 05:29 schrieb 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.
I do not know mkvtoolnix but when I read http://www.bunkus.org/videotools/mkvtoolnix/ it seems that the author does not really care about portability. Dropping support for everything before suse 12.1 which came out just a few weeks ago does not sound too nice. If there's no chance to get the author back on track I'd recommend to wait with updating and have a private playground for the most current release. Privately installing really big packages like boost and gcc and every c++ library that mkvtoolnix might use is not what I think macports was intended for. Regards Titus _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
