Encontré algo interesante durante mi desarrollo de C/C++ bajo Linux. Por ejemplo, hay 2 bibliotecas compartidas:
libfoo.so, que contiene 1 función:
//------------libfoo.h----------------- void func_foo(); //------------libfoo.c----------------- void func_foo() { return; }libbar.so, que contiene 2 funciones. Y uno de ellos depende de libfoo.so:
//-------------libbar.h--------------- void func_bar1(); void func_bar2(); //-------------libbar.c--------------- #include "libfoo.h" void func_bar1() { return; } void func_bar2() { return func_foo(); }Pero si un programa solo llama a func_bar1(), que es independiente de libfoo, el gcc/ld todavía intenta buscar el símbolo de func_bar2(), aunque el programa no lo necesita en absoluto. Por ejemplo:
//--------------------main.c------------ #include "libbar.h" int main(int argc, char** argv) { func_bar1(); return 0; }Entonces tengo el siguiente error al vincular:
gcc main.c -L . -lbar ./libbar.so: undefined reference to `func_foo'Así que tengo que hacerlo para que funcione:
gcc main.c -L . -lbar -lfooParece que el enlazador no puede resolver el símbolo func_bar1() en main.o, por lo que tiene que buscarlo en la siguiente lista de bibliotecas: libbar.so. Y todos los símbolos en libbar.so también deben verificarse, sin importar si el programa principal los necesita o no ... Pero no estoy seguro de entenderlo.
¿Podría alguien decirme cómo funciona realmente el enlace en este caso? ¿Y es posible evitar vincular a la libfoo 'innecesaria'?
¡Gracias por adelantado!
Cuando se menciona un archivo .so en un comando ld , se tratará como un archivo .o habitual. Como sabemos, todos los símbolos en un archivo .o (en este caso resulta libfoo.so ) deben resolverse. Es por eso que incluso en el programa main no llamas a func_foo() , aún se necesita resolver esa función.