man*_*hiz 10 c++ macos std libstdc++ libc++
现在Mac OS X上可以存在多个C++标准库,现在看起来非常混乱.根据/sf/answers/592045961/,混合libstdc ++和libc ++将导致链接错误,这会捕获这样的危险情况并且是一件好事.
另一方面,还有两种情况需要更多调查,我在github gist(https://gist.github.com/manphiz/7195515)中为此创建了一些测试用例.它确认混合链接到libstdc ++(来自系统或vanilla GNU GCC)和libc ++(系统)的动态库将导致链接错误.但是,如果一个动态库链接到系统libstdc ++,而另一个动态库链接到vanilla 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
Run Code Online (Sandbox Code Playgroud)
所以这里需要建议:
编译器信息:
$ 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)
Run Code Online (Sandbox Code Playgroud)
该系统是Mac OS X 10.9.
我不会代表Apple,但是看着他们的行动,我相信他们的目标是回到Mac OS(和iOS)的一个标准库实现 - 这将是libc ++.我相信在未来的某个时候,libstdc ++将不再是Mac OS X的一部分.
我们可以混合使用系统libc ++和手动构建的Clang libc ++吗?如果没有,什么时候会引起麻烦?
我经常这样做 - 但我没有替换usr/lib中的那个.而是在设置环境变量DYLD_LIBRARY_PATH以指向我新构建的libc ++之后运行特定程序.替换/ usr/lib中的那个可能会破坏你的系统.(如果你打破dylib中的某些东西 - 或者甚至只是更改布局std::string,比方说).
| 归档时间: |
|
| 查看次数: |
7397 次 |
| 最近记录: |