在Mac OS X上链接不同的C ++标准库 [英] Link different C++ standard libraries on Mac OS X

问题描述

现在Mac OS X上可以存在多个C ++标准库，现在看起来像是一个混乱的情况。根据 http://stackoverflow.com/a/8457799/1772681 ，混合libstdc ++和libc ++将导致链接错误，它捕获这种危险的情况，是一件好事。

另一方面，还有2种情况需要更多的调查，我已经创建了几个测试用例在github gist（ https://gist.github.com/manphiz/7195515 ）。它确认混合链接到libstdc ++（来自系统或香草GNU GCC）和libc ++（系统）的动态库将导致链接错误。然而，如果一个动态库链接到系统libstdc ++，而另一个动态库链接到香草GNU GCC libstdc ++，然后链接到一个二进制也可以工作，对于我的简单测试用例，它甚至可以在运行时。

  $ 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 
  

所以这里需要建议：

• 我们可以混合系统libstdc ++和手动构建的GNU GCC libstdc ++？


• 我们可以混合系统libc ++和手动构建的Clang libc ++吗？
  编译器信息：
  
  
  <$ p
  $ p> $ clang -v
Apple LLVM版本5.0（clang-500.2.79）（基于LLVM 3.3svn）
目标：x86_64-apple-darwin13.0.0
线程模型：posix

$ gcc-4.8 -v
使用内置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
目标：x86_64-apple-darwin13.0.0
配置为：../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
线程模型：posix
gcc version 4.8 .2（GCC）


  系统是Mac OS X 10.9。

  解决方案

  我不是说苹果，但看他们的行为，我相信他们的目标是回到一个标准库实现Mac OS（和iOS ） - 这将是libc ++。我相信在未来的某个时候，libstdc ++将不再是Mac OS X的一部分。

  
  

  我们可以混合系统libc ++和手动构建的Clang libc ++？

  
  

  我经常这样做 - 但我不会替换usr / lib中的那个。相反，我设置环境变量DYLD_LIBRARY_PATH指向我新建的libc ++之后运行特定的程序。替换/ usr / lib中的一个可能会导致系统崩溃。 （如果你打破了dylib中的东西 - 或者只是改变 std :: string 的布局）。

  
  

  Now that multiple C++ standard libraries can exist on Mac OS X, it now looks like quite a chaotic situation. According to http://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.

  解决方案

  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).

  这篇关于在Mac OS X上链接不同的C ++标准库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！