2010-09-02 15 views
7

Estoy experimentando con hacer una especie de arquitectura de complemento para un programa que escribí, y en mi primer intento tengo un problema. ¿Es posible acceder a símbolos desde el ejecutable principal desde dentro del objeto compartido? Pensé que estaría bien lo siguiente:objeto compartido no puede encontrar símbolos en el binario principal, C++

testlib.cpp:

void foo(); 
void bar() __attribute__((constructor)); 
void bar(){ foo(); } 

testexe.cpp:

#include <iostream> 
#include <dlfcn.h> 

using namespace std; 

void foo() 
{ 
    cout << "dynamic library loaded" << endl;  
} 

int main() 
{ 
    cout << "attempting to load" << endl; 
    void* ret = dlopen("./testlib.so", RTLD_LAZY); 
    if(ret == NULL) 
     cout << "fail: " << dlerror() << endl; 
    else 
     cout << "success" << endl; 
    return 0; 
} 

Compilado con:

g++ -fPIC -o testexe testexe.cpp -ldl 
g++ --shared -fPIC -o testlib.so testlib.cpp 

Salida:

attempting to load 
fail: ./testlib.so: undefined symbol: _Z3foov 

Así que, obviamente, no está bien. Supongo que tengo dos preguntas: 1) ¿Hay alguna manera de hacer que el objeto compartido encuentre símbolos en el ejecutable que se carga desde 2) De lo contrario, cómo funcionan los programas que usan complementos que logran obtener código en arbitrario objetos compartidos para ejecutar dentro de sus programas?

Respuesta

16

Probar:

g++ -fPIC -rdynamic -o testexe testexe.cpp -ldl 

Sin la -rdynamic (o algo equivalente, como -Wl,--export-dynamic), símbolos de la propia aplicación no estará disponible para la vinculación dinámica.

+0

Sí! Muchas muchas gracias. – cheshirekow

+1

Según https://gcc.gnu.org/onlinedocs/gcc-4.8.3/gcc/Link-Options.html, se puede lograr el mismo efecto con la opción "-rdinámica" en el paso del enlace gcc. –

+0

@TomBarron ¡Gracias! Actualizaré mi publicación. –

Cuestiones relacionadas