Encontré varias preguntas similares (p. Ej.esta, ese oesta), pero ninguno de ellos me ayudó a resolver mi problema. Tengo un archivo * .so (desde el núcleo degnss-sdr) que, como lo indica:

$nm libgnss_system_parameters_dyn.so  | c++filt  |grep Gps_Eph

contiene el símboloGps_Ephemeris::Gps_Ephemeris(), que se supone que es un constructor.

He escrito un código mínimo:

#include <iostream>
#include <core/system_parameters/gps_ephemeris.h>

int main(int argc,const char* argv[])
{
    Gps_Ephemeris ge;
    return 0; 
}

que compilo con:

g++  main.cpp -std=c++0x -I some_include_path -L some_lib_path -l gnss_system_parameters_dyn`

El enlazador luego se queja:

/tmp/ccHCvldG.o: In function `main':
main.cpp:(.text+0x33): undefined reference to `Gps_Ephemeris::Gps_Ephemeris()'
collect2: error: ld returned 1 exit status

También intentécmake, pero la línea que generó fue similar a esa (solo agregó-rdynamic antes de vincular), y aún generó exactamente el mismo error de vinculador.

Tenga en cuenta que tanto la biblioteca como mi código mínimo se están compilando con el mismo compilador (g ++ - 5), con los mismos indicadores y el mismo estándar c ++ 0x.

Dirigiendo la respuesta de Maxim Egorushkin, la línea:

nm --demangle --defined-only --extern-only libgnss_system_parameters.so  |grep Gps_Eph

no da salida a nada. Sin embargo, el símbolo se define en la biblioteca estática (es decir la biblioteca * .a):

00000000000006b0 T Gps_Ephemeris::Gps_Ephemeris()
00000000000006b0 T Gps_Ephemeris::Gps_Ephemeris()

Sabiendo que ambos son generados porcmake, de la siguiente manera:

add_library(lib_name SHARED ${sources_etc}) #for the *.so
add_library(lib_name_2 ${sources_etc}) #for the *.a

no debería haber diferencia en los símbolos contenidos / definidos en esas bibliotecas, ¿verdad? No noté nada encmakela documentación deadd_library. ¿Me estoy perdiendo algo obvio?