GCC and Clang: Library Incompatibility Issues in MacPorts
Jumble monolog (or quickly to What to do?)Currently, I'm using Boost libraries and C++11 features in my Xcode project. But there is a problem.
Boost libraries in my development environment was installed using MacPorts, and it seems these Boost libraries could not come along with C++11 features and LLDB in Xcode.
Let's make things clear, it is a GCC-Clang compatibility issue.
In Xcode build setting, you can choose GNU's libstdc++ for favor to Boost libraries (I'm not sure, but it seems they're built using GCC in my MacPorts environment), but then C++11 features and LLDB are crippled. Seemingly, libstdc++ provided by Apple LLVM is not C++11-ready.
Vice versa, you can choose LLVM's libc++ for favor to C++11 features and LLDB, but then Boost libraries are crippled.
I think the problem, on the surface, can be distilled to symbol name resolution failure.
For example, standard string type
std::stringin GNU's libstdc++ and
std::__1::stringin LLVM's libc++. Yes, they are different and incompatible.
Intension behind incompatible symbol naming convention in LLVM is due to difference of implementations of C++ standards between GCC and Clang; this is a safety measure to prevent different C++ implementations to mix within one program.
You can read brief explanation here → (see Stackoverflow answer).
What to do?
To avoid this GCC-Clang incompatibility mayhem, a simple and definite solution is to use a consistent toolchain throughout your development environment. This definitely prevents the trouble like this. But ports provided by MacPorts have their own preference and dislike for choice of compilers; in most cases /opt/bin/clang for Xcode 4.2 and later is used in MacPorts, or other compilers based on
compiler.blacklistin Portfile, and ports can be built and installed using different compilers in a long time span. Hell, what should we do!?
Relax, for some ports in MacPorts, maybe you can choose your desired compiler to build them.
What I'm thinking, and actually undertaking now, is to completely rebuild ALL "dev" category ports with Apple LLVM Clang (you can list those ports with command
port list category:dev and installed). I already uninstalled GCC related ports for certainty.
I like Clang for its user friendliness in warning and error messages (you can avoid consequence of bad programming like global naming pollution by warning option, and much more), and Xcode already transitioned to Clang; I think this is a good opportunity to tidy my development environment.