Cosa rende g ++ incluso GLIBCXX_3.4.9?

Question

Ho compilato 2 binari diversi sullo stesso server GNU / Linux usando g ++ versione 4.2.3.

Il primo utilizza:

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

Il secondo usa:

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

Perché il secondo binario usa GLIBCXX_3.4.9 che è disponibile solo su libstdc ++. so.6.0.9 e non in libstdc ++. so.6.0.8

Qual è la nuova funzionalità generata da g ++ che richiede un'interruzione ABI e impone al sistema di avere GLIBCXX_3.4.9?

Esiste un modo per disabilitare questa nuova funzione per non richiedere GLIBCXX_3.4.9?

Answer 1

Per scoprire da quale dei simboli GLIBCXX_3.4.9 elencati dipende effettivamente il tuo binario, procedere come segue:

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

Una volta che sai quali simboli cercare, puoi risalire all'oggetto che ne ha bisogno:

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

Infine, per ricollegarlo alla fonte, puoi fare:

objdump -dS foo.o

e vedi quale codice fa riferimento al simbolo 3.4.9.

Answer 2

Dato che l'hai richiesto, qui ci sono simboli che hanno almeno la versione 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;

Esegui il file libstdc ++ - v3 / config / abi / post / i386-linux-gnu / baseline_symbols.txt attraverso c ++ filt, cercando GLIBCXX_3.4.9 per dare un senso a quei nomi ( sembrano solo caratteri jolly). Non l'ho fatto perché quei nomi diventano piuttosto lunghi e nidificati. Le versioni successive includono principalmente materiale c ++ 1x. Vedere il file libstdc ++ - v3 / config / abi / pre / gnu.ver per quanto sopra. Leggi qui sul comando di script VERSION linker .

Answer 3

Bene, la prima domanda è come hai generato l'elenco sopra.
Si potrebbe presumere che il compilatore sia deterministico e quindi colleghi i binari allo stesso modo.

Presumo di essere stato segnato per non aver risposto direttamente alla domanda, ma sarebbe gradito un commento. Ma continuo a pensare che non hai fornito le informazioni corrette e sarebbe bello vedere l'output del comando che mostra il tuo problema.

Supponendo che hai usato ldd:
Otterresti un risultato simile al seguente:

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

Ma questa non è la fine della storia.
Provare a fare una ls sul file potrebbe essere un link simbolico

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