Was machen g ++ GLIBCXX_3.4.9 enthalten?

Question

I 2 verschiedene Binärdateien auf dem gleichen GNU / Linux-Server kompilierte mit g ++ Version 4.2.3.

Die erste verwendet:

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

Die zweite verwendet:

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

Warum die zweite binäre verwendet GLIBCXX_3.4.9, die nur auf libstdc ++ ist. So.6.0.9 und nicht in libstdc ++. So.6.0.8

Was ist die neue Funktion von g ++ erzeugt, die eine ABI Pause benötigen und das System zwingen GLIBCXX_3.4.9 haben?

Gibt es eine Möglichkeit, diese neue Funktion zu deaktivieren, um nicht GLIBCXX_3.4.9 erfordern?

Answer 1

Um herauszufinden, welche der aufgeführten GLIBCXX_3.4.9 Symbol (e) die Binärdatei hängt tatsächlich auf, dies zu tun:

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

Sobald Sie wissen, welche Symbole zu suchen, können Sie auf das Objekt zurückverfolgen, die sie braucht:

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

Schließlich diese zurück zur Quelle zu binden, die Sie tun können:

objdump -dS foo.o

und sieht, welcher Code verweist auf das 3.4.9-Symbol (s).

Answer 2

Da Sie darum gebeten, hier sind Symbole mit mindestens ABI Version 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;

Führen Sie die Datei libstdc++-v3/config/abi/post/i386-linux-gnu/baseline_symbols.txt durch c ++ filt, für GLIBCXX_3.4.9 greppen Sinn dieser Namen zu machen (sie wie Platzhalter aussehen nur). Ich habe es nicht getan, weil diese Namen sehr lang werden und verschachtelt. Spätere Versionen enthalten im Wesentlichen c ++ 1x Zeug. Siehe die Datei libstdc++-v3/config/abi/pre/gnu.ver für das oben. Lesen Sie hier über die Version Linker Script-Befehl .

Answer 3

Nun, die erste Frage wie haben generieren Sie die obige Liste.
Man würde annehmen, dass der Compiler deterministisch ist und damit verknüpfen Binärdateien auf die gleiche Weise.

Ich nehme an, ich habe markiert nach unten für die Frage nicht direkt beantworten, aber ein Kommentar wäre schön. Aber ich denke immer noch, haben Sie nicht die richtigen Informationen zur Verfügung gestellt und es wäre schön, die Ausgabe des Befehls, um zu sehen, die Ihr Problem zeigt.

Angenommen, Sie ldd verwendet:
Sie würden eine Ausgabe erhalten, die wie folgt aussah:

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

Aber das ist nicht das Ende der Geschichte.
tut eine ls auf die Datei versucht, kann es sich um eine symbolische Verbindung sein

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