2010-11-09 14 views
29

Si compilo un programa C++ en mi máquina y lo ejecuto en otro (con un software anterior) obtengo: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found.GLIBCXX versiones

De hecho en mi glibc sistema es más reciente (Tengo gcc-libs 4.5.1: libstdC++ so.6.0.14.) Y strings /usr/lib/libstdc++.so.6 | grep GLIBCXX impresiones de GLIBCXX_3.4 a GLIBCXX_3.4.14. En el otro sistema, en cambio, solo se imprime hasta GLIBCXX_3.4.8 (obtuve libstdC++. So.6.0.8).

así que tengo un par de preguntas:

  1. Por qué mi enlazador enlaza los binarios C++ contra libstdC++ versión GLIBCXX_3.4.9 en lugar de GLIBCXX_3.4.14?

  2. Si cumplí mi código binario contra libstdC++ versión GLIBCXX_3.4 supongo que se ejecutará casi en todas partes. ¿Eso implicaría algún tipo de problema? (Por ejemplo: habría que utilizar más edad -y por lo tanto peor, las implementaciones del algoritmo?)

  3. Si en lugar de eso estáticamente vinculo mi programa en contra de mi libstdC++ supongo que se ejecutará en todas partes; el binario será mucho más grande (~ 1MB) por supuesto, cualquier otro pros/contras?

  4. ¿Puedo forzar al enlazador a vincular mi binario con una versión determinada de libstdC++?

+2

Debería utilizar 'objdump' para inspeccionar la biblioteca, no' cadenas'. –

Respuesta

30

Utilice readelf -a y objdump -x para inspeccionar los archivos ELF con preferencia a strings.

En realidad, todas las versiones GLIBCXX_ * no se aplican a toda la biblioteca, sino a cada símbolo (versión de símbolo, ver DSO-howto). Por lo tanto, puede tener, por ejemplo: std::char_traits<wchar_t>::[email protected]@GLIBCXX_3.4.5 y std::ios_base::Init::~Init()@@GLIBCXX_3.4 en el mismo archivo de biblioteca.

El hecho de que su programa necesite GLIBCXX_3.4.9 probablemente significa que se ha vinculado con un símbolo que se ha introducido/ha cambiado la semántica en GLIBCXX_3.4.9.

+0

Uh, esto explica un montón de cosas, ¡gracias! – peoro

+0

También C++ filt puede ser útil si tiene código C++. Por ejemplo: readelf -aW | C++ filt – jcoffland

0
  1. Que la biblioteca de la versión que está instalada en su sistema. Puede construir manualmente la versión 3.4.14 de glibc y vincularla a ella
  2. Eso depende. Tal vez la versión posterior solucionó algunos problemas. Los usuarios de su programa tendrían que vincularse con la versión que requiere su programa
  3. El uso de memoria es mayor
  4. Sí, pase el parámetro adecuado al enlazador. Si necesita una versión específica de la biblioteca, entonces es mejor descargarla, compilarla manualmente y vincularla.

EDITAR

acabo de recordar que las bibliotecas enlazadas estáticamente aumentan el uso de la memoria.

+0

1: Eso no es todo. Inténtalo de nuevo. 3: incorrecto –

+0

@Ignacio Vazquez-Abrams Así que obtuve 2 de 4. Por 1), creo que faltan dependencias para glibc. Si 3 no es correcto, creo que vivo en la ignorancia. Entonces, ¿cómo corregir esos dos? –

+0

1 No estoy seguro, pero la biblioteca sí tiene 'GLIBCXX_3.4.14' *, simplemente no la usa por algún motivo. Para 3, considere las implicaciones de no poder actualizar la biblioteca. –

-1

En mi opinión, si tus binarios no usan las nuevas características de la versión GLIBCXX más nueva, entonces no se vincularán con esa versión. Por lo tanto, sus binarios estaban vinculados con GLBCXX 3.4.9, debe haber al menos un símbolo exportado desde allí, y no hay símbolos exportados desde la versión más nueva que la 3.4.9.