¿Qué hace que g ++ incluya GLIBCXX_3.4.9?

Question

Compilé 2 binarios diferentes en el mismo servidor GNU / Linux usando g ++ versión 4.2.3.

El primero usa:

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

El segundo utiliza:

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

Por qué el segundo binario usa GLIBCXX_3.4.9 que solo está disponible en libstdc ++. so.6.0.9 y not en libstdc ++. so.6.0.8

¿Cuál es la nueva característica generada por g ++ que requiere una interrupción ABI y obliga al sistema a tener GLIBCXX_3.4.9?

¿Hay alguna forma de deshabilitar esta nueva función para no requerir GLIBCXX_3.4.9?

Answer 1

Para saber en cuál de los símbolos GLIBCXX_3.4.9 de la lista depende su binario, haga esto:

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

Una vez que sepa qué símbolos buscar, puede rastrear hasta el objeto que los necesita:

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

Finalmente, para vincular esto de nuevo a la fuente, puede hacer:

objdump -dS foo.o

y vea qué código hace referencia a los símbolos 3.4.9.

Answer 2

Desde que lo solicitó, aquí hay símbolos que tienen al menos ABI versión 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;

Ejecute el archivo libstdc ++ - v3 / config / abi / post / i386-linux-gnu / baseline_symbols.txt a través de c ++ filt, grepping para que GLIBCXX_3.4.9 comprenda esos nombres ( se ven como comodines solamente). No lo hice porque esos nombres se vuelven bastante largos y están anidados. Las versiones posteriores incluyen principalmente cosas de C ++ 1x. Consulte el archivo libstdc ++ - v3 / config / abi / pre / gnu.ver para ver lo anterior. Lea aquí sobre el comando de script VERSION linker .

Answer 3

Bueno, la primera pregunta es cómo generó la lista anterior.
Se podría suponer que el compilador es determinista y, por lo tanto, vincula los binarios de la misma manera.

Supongo que quedé marcado por no responder la pregunta directamente, pero un comentario sería bueno. Pero sigo pensando que no ha proporcionado la información correcta y sería bueno ver la salida del comando que muestra su problema.

Suponiendo que usaste ldd:
Obtendrías una salida como esta:

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

Pero este no es el final de la historia.
Intentar hacer una ls en el archivo puede ser un enlace simbólico

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