¿El programa necesita símbolos adicionales de la biblioteca compartida .so excepto aquellos declarados en el archivo de encabezado?

Question

En la programación C, pensé que un archivo objeto se puede vincular con éxito con un archivo .so, siempre que el archivo .so ofrezca todos los símbolos que se han declarado en el archivo de encabezado.

Supongamos que tengo foo.c, bar.h y dos bibliotecas libbar.so.1 y libbar.so.2. La implementación de libbar.so.1 y libbar.so.2 es totalmente diferente, pero creo que está bien siempre y cuando ambos ofrezcan funciones declaradas en bar.h.

Vinculaba foo.o con libbar.so.1 y producía un archivo ejecutable: foo.bin. Este ejecutable funcionó cuando libbar.so.1 está en LD_LIBRARY_PATH. (Por supuesto, un enlace simbólico se hace como libbar.so) Sin embargo, cuando cambio el enlace simbólico a libbar.so.2, foo.bin no pudo ejecutar y se lo impidió :

undefined symbol: _ZSt4cerr 

libbar.so.1 es una biblioteca compilada en C++, mientras que libbar.so.2 es una biblioteca compilada. No entiendo por qué foo.bin necesita esos símbolos relacionados con C++ que solo son significativos en libbar.so.1, ya que foo.bin se basa en el código c puro foo.c.

Answer 1

_ZSt4cerr es obviamente un nombre C++ destrozado. Puede que necesite comprobar si está utilizando el compilador correcto (gcc/g ++, sé que suena estúpido, pero me encontré con tanta confusión;)), y si hay alguna macro en el archivo bar.h que podría tener cerr referenciado

Answer 2

Debe exigir el nombre de C++ antes de buscar. Para gcc hay una utilidad C++ filt:

$ c++filt 
_ZSt4cerr 
std::cerr 

Es solo un flujo de archivos de error estándar.

Answer 3

Probablemente haya olvidado vincular todo el programa con la biblioteca estándar de C++.

Answer 4

La afirmación en la pregunta es incorrecta. Usted dice 'el archivo de encabezado'. No existe el 'el (uno y único) archivo de encabezado'. Si te refieres a 'el archivo de cabecera que declara una cierta clase de C++', bueno, esa clase podría heredar de otras clases. O podría usar excepciones. O RTTI. En cuyo caso, de forma predeterminada, el .so que contiene el código que lo acompaña contendrá "símbolos indefinidos colgantes". Por defecto, la expectativa es que el programa 'principal' esté en C++, y se vincule con el tiempo de ejecución de C++.

Es posible para crear un .so autónomo, pero tiene que hacer un trabajo extra para crearlo. Puede necesitar usar -Bsymbolic, o especificar algunas -l bibliotecas al vincularlo, o ambos. Esta área no está bien documentada y generalmente requiere algo de arqueología.