Link different C++ standard libraries on Mac OS X
Now that multiple C++ standard libraries can exist on Mac OS X, it now looks like quite a chaotic situation. According to https://stackoverflow.com/a/8457799/1772681, mixing libstdc++ and libc++ will result in link error, which catches such dangerous situation and is a good thing.
On the other hand, There are still 2 situations need more investigation, and I have created a few test cases for this in github gist (https://gist.github.com/manphiz/7195515). It confirms that mixing dynamic libraries that link to libstdc++ (either from system or vanilla GNU GCC) and libc++ (system) will result in link error. However, if one dynamic library links to system libstdc++, while another dynamic library links to vanilla GNU GCC libstdc++, and then link both into a binary also works, and for my simple test case it even works in runtime.
$ make -f Makefile.system_gnu
g++-4.8 -g -Wall -fPIC -o main.o -c main.cc
g++-4.8 -g -Wall -fPIC -o test_a.o -c test_a.cc
g++-4.8 -dynamiclib -o libtest_a.dylib test_a.o
clang++ -g -Wall -fPIC "-stdlib=libstdc++" -o test_b.o -c test_b.cc
clang++ -dynamiclib "-stdlib=libstdc++" -o libtest_b.dylib test_b.o
g++-4.8 -o test main.o -L. -ltest_a -ltest_b
$ ./test
main_test_a_test_b
So here advice is needed:
- Can we mix system libstdc++ and manually built GNU GCC libstdc++? If not, when will it cause trouble?
- Can we mix system libc++ and manually built Clang libc++? If not, when will it cause trouble?
Compilers information:
$ clang -v
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix
$ gcc-4.8 -v
Using built-in specs.
COLLECT_GCC=gcc-4.8
COLLECT_LTO_WRAPPER=/opt/homebrew/Cellar/gcc48/4.8.2/libexec/gcc/x86_64-apple-darwin13.0.0/4.8.2/lto-wrapper
Target: x86_64-apple-darwin13.0.0
Configured with: ../configure --build=x86_64-apple-darwin13.0.0 --prefix=/opt/homebrew/Cellar/gcc48/4.8.2 --enable-languages=c,c++,fortran,java,objc,obj-c++ --program-suffix=-4.8 --with-gmp=/opt/homebrew/opt/gmp4 --with-mpfr=/opt/homebrew/opt/mpfr2 --with-mpc=/opt/homebrew/opt/libmpc08 --with-cloog=/opt/homebrew/opt/cloog018 --with-isl=/opt/homebrew/opt/isl011 --with-system-zlib --enable-version-specific-runtime-libs --enable-libstdcxx-time=yes --enable-stage1-checking --enable-checking=release --enable-lto --disable-werror --enable-plugin --disable-nls --with-ecj-jar=/opt/homebrew/opt/ecj/share/java/ecj.jar --enable-multilib
Thread model: posix
gcc version 4.8.2 (GCC)
The system is Mac OS X 10.9.
Answer
I don't speak for Apple, but watching their actions, I believe that their goal is to get back to one standard library implementation for Mac OS (and iOS) - and that will be libc++. I believe that sometime in the future, libstdc++ will no longer be part of Mac OS X.
Can we mix system libc++ and manually built Clang libc++? If not, when will it cause trouble?
I do this fairly regularly - but I don't replace the one in usr/lib. Instead I run specific programs after setting the environment variable DYLD_LIBRARY_PATH to point to my newly built libc++. Replacing the one in /usr/lib has the potential to brick your system. (if you break something in the dylib - or even just change the layout of std::string, say).