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

Question

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

Le premier utilise:

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

Le second 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 uniquement disponible 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 oblige le système à utiliser GLIBCXX_3.4.9?

Existe-t-il un moyen de désactiver cette nouvelle fonctionnalité pour ne pas requérir GLIBCXX_3.4.9?

Answer 1

Pour déterminer le (s) symbole (s) GLIBCXX_3.4.9 répertorié (s) dont dépend réellement le binaire, procédez comme suit:

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 en a besoin:

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

Enfin, pour rattacher cela à 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

Depuis que vous l'avez demandé, voici les symboles ayant au moins la version 3.4.9 d'ABI:

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 via c ++ filt, en recherchant GLIBCXX_3.4.9 pour donner un sens à ces noms ( ils ressemblent à des caractères génériques uniquement). Je ne l'ai pas fait parce que ces noms deviennent assez longs et imbriqués. Les versions ultérieures incluent principalement des choses c ++ 1x. Voir le fichier libstdc ++ - v3 / config / abi / pre / gnu.ver pour ce qui précède. Lisez ici sur la commande de script VERSION linker .

Answer 3

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 relier ainsi les fichiers binaires de la même manière.

Je suppose que je me suis fait reprocher de ne pas avoir répondu directement à la question, mais un commentaire serait bien. Mais je pense toujours que vous n’avez pas fourni les informations correctes et que ce serait bien de voir le résultat de la commande qui montre votre problème.

En supposant que vous avez utilisé ldd:
Vous obtiendrez un résultat ressemblant à ceci:

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

Mais ce n'est pas la fin de l'histoire.
Essayer de faire un ls sur le fichier 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>