ELF: linking: ¿Por qué obtengo referencias indefinidas en .so archivos

Question

Estoy tratando de construir un programa contra wxWidgets, y me sale un error de enlazador. Me gustaría realmente entender lo que significa. El error es:

/usr/lib/libwx_baseu-2.8.so: undefined reference to `std::ctype<char>::_M_widen_init() const@GLIBCXX_3.4.11' 

Lo que no entiendo es por eso que el error está en libwx_baseu-2.8.so. Pensé que los archivos .so tenían todos sus símbolos resueltos, al contrario de los archivos .o que aún necesitan vincularse.

Cuando ldd la .so, consigo puede resolver todas sus bibliotecas enlazadas, así que no hay problema allí:

$ ldd /usr/lib/libwx_baseu-2.8.so 
linux-gate.so.1 => (0x00476000) 
libz.so.1 => /lib/libz.so.1 (0x00d9c000) 
libdl.so.2 => /lib/libdl.so.2 (0x002a8000) 
libm.so.6 => /lib/libm.so.6 (0x00759000) 
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x002ad000) 
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0068d000) 
libpthread.so.0 => /lib/libpthread.so.0 (0x006f0000) 
libc.so.6 => /lib/libc.so.6 (0x00477000) 
/lib/ld-linux.so.2 (0x007f6000) 

Qué significa que el archivo .so no fue compilado correctamente (en ese caso, es un error en mi paquete de distribución) o significa que faltan bibliotecas en la línea de comando del enlazador para mi programa en particular?

Además, ¿sabes cómo puedo obtener una lista de símbolos indefinidos en un archivo ELF. Intenté readelf -s pero no puedo encontrar el símbolo que falta.

Gracias.

Mildred

Answer 1

creo que no vincula a algunas de las bibliotecas al vincular su programa.

Debe enlazar en su programa a todas las bibliotecas compartidas con los que enlace en su .so

Si el .so está vinculado a algunas bibliotecas estáticas - no se requiere en el programa de vincular a ellos si todos los símbolos necesarios se encuentran en el .so

Es posible utilizar nm de comandos de Linux para ver los símbolos en el archivo objeto, biblioteca o binaria

Editar
su problema particular puede ser descrito aquí: http://old.nabble.com/-Bug-49433--gcc4.4,-NEW:-gcc4.4-misses-std::endl-implementation-at--O2%2B-td22836171.html

Answer 2

I thought that .so files had all its symbols resolved, contrary to .o files that still need linking.

bibliotecas compartidas pueden ser incompletos, es decir OK.

do you know how I can get a list on undefined symbols in an ELF file

Uso

nm -C -u libwx_baseu-2.8.so

Answer 3

Cuando se vincula una biblioteca compartida contra otras bibliotecas compartidas (por ejemplo enlace libwx_baseu-2.8.so contra libstdc++.so), los registros de engarce símbolos utilizados por libwx_baseu y proporcionados por libstdc++ versionados.

Si en el tiempo de ejecución utiliza una copia diferente de libstdc++ (una que no proporciona los mismos símbolos versionados), obtiene un error (dinámico) de simpatía y el programa no se ejecuta (esto es preferible a una falla "misteriosa" más adelante).

Pero lo que sucede aquí es que intentas vincular un ejecutable, lo que significa que el vinculador (estático) quiere encontrar todos los símbolos que serán necesarios en el tiempo de ejecución.Nuevamente, está vinculando el archivo ejecutable con un archivo libstdc++.so diferente (anterior), por lo que falla el enlace.

Hay dos causas fundamentales habituales:
- o bien se enlazó libwx_baseu-2.8.so en un sistema diferente (uno con nueva versión de GCC), y copiado en el sistema actual, o
- que ha enlazado con un libwx_baseu-2.8.so GCC más nuevo en el mismo sistema, pero ahora están tratando de vincular el ejecutable con un GCC antiguo.

Answer 4

Pruebe: poniendo -fno-en línea en sus banderas en Makefile. Básicamente, g ++ 4.4 está teniendo problemas sin él. Intenta ponerlo O elimina la opción -O. Solucionó el mismo problema que tuve.