librería compartida de Linux que utiliza un símbolo indefinido biblioteca compartida

dos bibliotecas compartidas liba.so y libb.so. liba.so usa libb.so. Todos los archivos c se compilan con -fPIC. El enlace usa -share. Cuando llamamos dlopen en liba.so no puede encontrar símbolos en libb.so ... nosotros conseguimos el error "símbolo indefinido". Podemos drenar libb.so sin errores. Sabemos que liba está encontrando libb porque no obtenemos un error de archivo no encontrado. Obtenemos un error de archivo no encontrado cuando eliminamos libb.so. Intentamos -lutil y sin suerte.librería compartida de Linux que utiliza un símbolo indefinido biblioteca compartida

Alguna idea ????

oh sí. gcc 4.1.2

actualización: Utilizamos rpath al vincular Liba por lo que puede encontrar libB.

LDD liba.so devuelve:.

linux-gate.so.1 => (0xffffe000) 
libb.so => ./libb.so (0xf6ef9000) <-------- LIBB 
libutil.so.1 => /lib/libutil.so.1 (0xf6ef5000) 
libdl.so.2 => /lib/libdl.so.2 (0xf6ef1000) 
libm.so.6 => /lib/libm.so.6 (0xf6ec9000) 
libpthread.so.0 => /lib/libpthread.so.0 (0xf6eb1000) 
librt.so.1 => /lib/librt.so.1 (0xf6ea8000) 
libc.so.6 => /lib/libc.so.6 (0xf6d62000) 
/lib/ld-linux.so.2 (0x007d0000)

es que significat que no hay una # al final de libB ???

Fuente

2010-06-07 johnnycrash

Usted dice: creó dos libs (-fPIC -shared), liba.so y libb.so. liba.so está vinculado dinámicamente (o debería ser ...) con libb.so y lo usa. En un programa X intenta dlopen en libb.so y todo está bien; otro programa de prueba Y intenta liberar liba.so pero falla, sin embargo, usted sabe que liba.so encuentra libb.so correctamente ya que trató de eliminar libb.so y surge otro problema ... ¿opciones que está usando para dlopen? – ShinTakezou

Lo tienes todo bien. En este momento no usamos ninguna opción, porque se llama a dlopen desde algún programa sobre el que no tenemos control. – johnnycrash

¿Qué dice el comando 'ldd liba.so' decir? –

Puede comprobar fácilmente donde se espera libb.so estar con ldd comando:

$ ldd liba.so 
    linux-gate.so.1 => (0xb77b0000) 
    libb.so.1 => not found 
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb75b6000) 
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7572000) 
    libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb742b000) 
    /lib/ld-linux.so.2 (0xb77b1000)

Si se trata de not found, ruta libb.so 's, debe añadirse a /etc/ld.so.conf o envuelta variables LD_LIBRARY_PATH.

Otra forma es configurar rpath en el propio liba.so - básicamente es una codificación rígida de su ruta por lo que cuando se inicia el binario, el vinculador dinámico sabría dónde buscar las bibliotecas compartidas.

Si rpath no se establece que buscará primero en LD_LIBRARY_PATH, entonces los caminos mencionados en /etc/ld.so.conf (o /etc/ld.so.conf.d/). Después de añadir a ls.so.conf no se olvide de ejecutar /sbin/ldconfig

enlazador dinámico busca en las bibliotecas compartidas dependientes por su soname (si está configurado) - si no se establece soname (con -Wl, -soname, para libb.so.1 ejemplo), se buscará por nombre de la biblioteca.

Ejemplo: libb.so.1.0 es su biblioteca real, teniendo soname - libb.so.1. Que normalmente tienen la siguiente estructura de archivos:

libb.so -> libb.so.1 
libb.so.1 -> libb.so.1.0 
libb.so.1.0

donde libb.so y libb.so.1 son enlaces simbólicos.

Suele establecer un enlace con libb.so, al compilar alguna aplicación u otra biblioteca, según libb.so.

gcc -shared -Wl,-soname,liba.so.1 -o liba.so.1.2 -L/libb/path -lb

Cuando se inicia la aplicación (o dlopen se ejecuta - su caso) - enlazador dinámico buscará el archivo con el nombre libb.so.1 - la soname de la biblioteca dependiente, si se establece el soname, no libb.so.

Es por eso que necesita ese enlace simbólico libb.so.1, apuntando a la biblioteca real.

Si utiliza ld.so.conf y ldconfig, se va a crear el enlace simbólico con el nombre soname 's, que apunta al archivo de la biblioteca, si este enlace simbólico no se encuentra.

Puede ver la página de manual de ld-linux para obtener más información útil.

Si no se encuentra la biblioteca, pero algunos de los símbolos que faltan, tratar de construir libb.so con -Wl,--no-undefined opción

gcc -shared -Wl,-soname,libb.so.1 -Wl,--no-undefined -o libb.so.1.2

Se le debe dar un error si se ha perdido para definir un símbolo.

Fuente

2010-06-07 17:24:40

usamos rpath. Estamos bastante seguros de que está encontrando la biblioteca, porque tratamos de ejecutar la aplicación después de eliminar libb y obtenemos un error de archivo no encontrado. Cuando ejecutamos con libb obtenemos un error de símbolo indefinido. – johnnycrash

Felicitaciones por rpath .... pero no es nuestro problema. – johnnycrash

es posible que no haya entendido la parte sobre soname ... ¿puedes aclarar un poco? – johnnycrash

No se olvide que el orden libs (todos los argumentos -lxxx) son importantes (por lo menos en gcc) al vincular todas sus objs & bibliotecas para generar el ejecutable.

ejemplo corta:

LIBS = -L. -ltest1 -ltest2

OBJS = code1.o code2.o

gcc $ (LIBS) $ (OBJS) -O mysoft

que puede fallar en algunos casos, mientras que

gcc $ (OBJS) -o mysoft $ (LIBS)

no lo hará

Fuente

2015-04-21 14:31:14

librería compartida de Linux que utiliza un símbolo indefinido biblioteca compartida

Respuesta

Cuestiones relacionadas