在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屋!