Qu'est-ce qui fait que g ++ inclut GLIBCXX_3.4.9?

Question

J'ai compilé 2 binaires différents sur le même serveur GNU/Linux en utilisant g ++ version 4.2.3.

Le premier utilise:

GLIBC_2.0 
GLIBC_2.2 
GLIBC_2.1 
GLIBCXX_3.4 
GLIBC_2.1.3 

La seconde utilise:

GLIBC_2.0 
GLIBC_2.2 
GLIBC_2.1 
GLIBCXX_3.4.9 
GLIBCXX_3.4 
GLIBC_2.1.3 

Pourquoi le second binaire utilise GLIBCXX_3.4.9 qui est disponible uniquement sur libstdC++ so.6.0.9 et . pas dans libstdC++. so.6.0.8

Quelle est la nouvelle fonctionnalité générée par g ++ qui nécessite une interruption ABI et force le système à avoir GLIBCXX _3.4.9?

Y at-il un moyen de désactiver cette nouvelle fonctionnalité pour ne pas exiger GLIBCXX_3.4.9?

Answer 1

Pour en savoir qui du symbole de la liste GLIBCXX_3.4.9 (s) de votre binaire dépend en fait, faites ceci:

readelf -s ./a.out | grep 'GLIBCXX_3\.4\.9' | c++filt 

Une fois que vous savez quels symboles à rechercher, vous pouvez remonter à l'objet qui a besoin d'eux:

nm -A *.o | grep _ZN<whatever> 

Enfin, pour attacher ce retour à la source, vous pouvez faire:

objdump -dS foo.o 

et voyez quel code fait référence au (x) symbole (s) 3.4.9.

Answer 2

Eh bien, la première question est de savoir comment vous avez généré la liste ci-dessus.
On pourrait supposer que le compilateur est déterministe et donc relier les binaires de la même manière.

Je suppose que j'ai été marqué pour ne pas répondre directement à la question, mais un commentaire serait bien. Mais je pense toujours que vous n'avez pas fourni les informations correctes et ce serait bien de voir la sortie de la commande qui montre votre problème.

En supposant que vous utilisez ldd:
Vous obtenez une sortie qui ressemblait à ceci:

lib<X>.so.<ver> => /usr/lib/lib<X>.so.<verM> (<Addr>) 

Mais ce n'est pas la fin de l'histoire.
fait un ls Essayant sur le fichier, il peut être un lien symbolique

> ls /usr/lilb/lib<X>.so.<verM> 
lrwxrwxrwx 1 root root <Date> /usr/lib/lib<X>.so.<verM> -> lib<X>.so.<verM>.<verm>.<verp> 

Answer 3

Depuis que vous avez demandé, voici des symboles ayant au moins la version 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; 

Exécutez le fichier libstdc++-v3/config/abi/post/i386-linux-gnu/baseline_symbols.txt à travers C++ filt, grepping pour GLIBCXX_3.4.9 pour donner un sens à ces noms (ils ressemblent à des caractères génériques seulement). Je ne l'ai pas fait parce que ces noms deviennent assez longs et imbriqués. Les versions ultérieures incluent principalement des éléments C++ 1x. Voir le fichier libstdc++-v3/config/abi/pre/gnu.ver pour le dessus. Lisez here à propos de la commande de script VERSION linker.