Свяжите различные стандартные библиотеки С++ в Mac OS X

Теперь, когда в Mac OS X существует несколько стандартных библиотек С++, теперь это выглядит довольно хаотичной ситуацией. Согласно qaru.site/info/27041/..., смешение libstdС++ и libС++ приведет к ошибке ссылки, которая улавливает такую ​​опасную ситуацию и является хорошей вещью.

С другой стороны, Есть еще 2 ситуации требуют больше исследований, и я создал несколько тестовых примеров для этого в github gist (https://gist.github.com/manphiz/7195515). Он подтверждает, что смешивание динамических библиотек, которые ссылаются на libstdС++ (либо из системы, либо с помощью GNU GCC GNU) и libС++ (system), приведет к ошибке ссылки. Однако, если одна динамическая библиотека связана с системой libstdС++, в то время как другая динамическая библиотека ссылается на vanilla GNU GCC libstdС++, а затем связывает оба с бинарником, также работает, и для моего простого тестового примера он даже работает во время выполнения.

$ 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

Итак, здесь нужен совет:

  • Можно ли смешивать систему libstdС++ и вручную встроенный GNU GCC libstdС++? Если нет, когда это вызовет проблемы?
  • Можно ли смешивать систему libС++ и вручную созданный Clang libС++? Если нет, когда это вызовет проблемы?

Информация о компиляторах:

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

Система Mac OS X 10.9.

Ответ 1

Я не говорю за Apple, но, наблюдая за их действиями, я считаю, что их цель - вернуться к одной стандартной реализации библиотеки для Mac OS (и iOS) - и это будет libС++. Я полагаю, что когда-нибудь в будущем libstdС++ больше не будет частью Mac OS X.

Можно ли смешивать систему libС++ и вручную созданный Clang libС++? Если нет, когда это вызовет проблемы?

Я делаю это довольно регулярно, но я не заменяю его в usr/lib. Вместо этого я запускаю определенные программы после установки переменной окружения DYLD_LIBRARY_PATH, чтобы указать на мой недавно созданный libС++. Замена одного в /usr/lib может привести к блокировке вашей системы. (если вы что-то сломаете в dylib - или даже просто измените расположение std::string, скажем).