Что заставляет g ++ включать GLIBCXX_3.4.9?
-
05-07-2019 - |
Вопрос
Я скомпилировал 2 разных двоичных файла на одном сервере GNU / Linux, используя g ++ версии 4.2.3.
Первый использует:
GLIBC_2.0
GLIBC_2.2
GLIBC_2.1
GLIBCXX_3.4
GLIBC_2.1.3
Второй использует:
GLIBC_2.0
GLIBC_2.2
GLIBC_2.1
GLIBCXX_3.4.9
GLIBCXX_3.4
GLIBC_2.1.3
Почему второй двоичный файл использует GLIBCXX_3.4.9, который доступен только в libstdc ++. so.6.0.9 и не в libstdc ++. so.6.0.8
Что представляет собой новая функция, созданная g ++, которая требует прерывания ABI и вынуждает систему иметь GLIBCXX_3.4.9?
Есть ли способ отключить эту новую функцию, чтобы не требовать GLIBCXX_3.4.9?
Решение
Чтобы узнать, от какого из перечисленных символов GLIBCXX_3.4.9 зависит ваш двоичный файл, сделайте следующее:
readelf -s ./a.out | grep 'GLIBCXX_3\.4\.9' | c++filt
Как только вы узнаете, какие символы искать, вы можете вернуться к объекту, который нуждается в них:
nm -A *.o | grep _ZN<whatever>
Наконец, чтобы привязать это к источнику, вы можете сделать:
objdump -dS foo.o
и посмотрите, какой код ссылается на символ (ы) 3.4.9.
Другие советы
Поскольку вы просили об этом, вот символы, по крайней мере, ABI версии 3.4.9:
GLIBCXX_3.4.9 {
_ZNSt6__norm15_List_node_base4hook*;
_ZNSt6__norm15_List_node_base4swap*;
_ZNSt6__norm15_List_node_base6unhookEv;
_ZNSt6__norm15_List_node_base7reverseEv;
_ZNSt6__norm15_List_node_base8transfer*;
_ZNSo9_M_insertI[^g]*;
_ZNSt13basic_ostreamIwSt11char_traitsIwEE9_M_insertI[^g]*;
_ZNSi10_M_extractI[^g]*;
_ZNSt13basic_istreamIwSt11char_traitsIwEE10_M_extractI[^g]*;
_ZSt21__copy_streambufs_eofI[cw]St11char_traitsI[cw]EE[il]PSt15basic_streambuf*;
_ZSt16__ostream_insert*;
_ZN11__gnu_debug19_Safe_sequence_base12_M_get_mutexEv;
_ZN11__gnu_debug19_Safe_iterator_base16_M_attach_singleEPNS_19_Safe_sequence_baseEb;
_ZN11__gnu_debug19_Safe_iterator_base16_M_detach_singleEv;
_ZN11__gnu_debug19_Safe_iterator_base12_M_get_mutexEv;
_ZNKSt9bad_alloc4whatEv;
_ZNKSt8bad_cast4whatEv;
_ZNKSt10bad_typeid4whatEv;
_ZNKSt13bad_exception4whatEv;
} GLIBCXX_3.4.8;
Запустите файл libstdc ++ - v3 / config / abi / post / i386-linux-gnu / baseline_symbols.txt
через c ++ Filta, чтобы найти GLIBCXX_3.4.9, чтобы разобраться в этих именах ( они похожи только на символы подстановки). Я этого не делал, потому что эти имена становятся довольно длинными и вложенными. Более поздние версии в основном включают c ++ 1x. Смотрите выше файл libstdc ++ - v3 / config / abi / pre / gnu.ver
. Прочитайте здесь о команде сценария компоновщика VERSION , Р>
Ну, первый вопрос: как вы создали приведенный выше список?
Можно предположить, что компилятор является детерминированным и, таким образом, связывает двоичные файлы одинаково.
Полагаю, я получил оценку за то, что не ответил на вопрос напрямую, но комментарий был бы хорош. Но я все еще думаю, что вы не предоставили правильную информацию, и было бы неплохо увидеть выходные данные команды, которая показывает вашу проблему.
Предполагается, что вы использовали ldd:
Вы бы получили вывод, который выглядел так:
lib<X>.so.<ver> => /usr/lib/lib<X>.so.<verM> (<Addr>)
Но это не конец истории.
Попытка выполнить ls для файла может быть символической ссылкой
> ls /usr/lilb/lib<X>.so.<verM>
lrwxrwxrwx 1 root root <Date> /usr/lib/lib<X>.so.<verM> -> lib<X>.so.<verM>.<verm>.<verp>