#40231: mkvtoolnix: fix build with clang ---------------------------+-------------------------------- Reporter: ryandesign@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Resolution: | Keywords: Port: mkvtoolnix | ---------------------------+-------------------------------- Comment (by jeremyhu@…): Replying to [comment:4 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++. -- Ticket URL: <https://trac.macports.org/ticket/40231#comment:7> MacPorts <http://www.macports.org/> Ports system for OS X