ajuste de Mi lib para LD_PRELOAD hace algunos procesos producen errores cargador

me sale el siguiente error al intentar ejecutar un script sólo tengo acceso de ejecución para:ajuste de Mi lib para LD_PRELOAD hace algunos procesos producen errores cargador

uname: symbol lookup error: /home/dumindara/random/sotest/a.out: undefined symbol: dlsym

Esto es después de haber establecido LD_PRELOAD entorno variable a /home/dumindara/random/sotest/a.out.

a.out tiene una función de prueba malloc, y llama internamente al dlsym.

No consigo este problema al ejecutar ls. La mayoría de los procesos dan este error. ¿Por qué sucede esto y qué puedo hacer para que funcione?

Fuente

2010-12-08 nakiya

Por lo general es un buen idea de establecer LD_PRELOAD solo para a.out, en lugar de modificar el entorno de shell. En la mayoría de las shells de UNIX puede escribir: 'LD_PRELOAD = xyz./A.out'. De lo contrario, intente '(LD_PRELOAD = xyz; ./a.out)'. –

@Tony: creo que a.out es un objeto compartido en este caso, a pesar de su nombre mal elegido. El OP aparentemente intenta anular 'malloc()' con su propia versión y luego pasar al malloc real. – thkala

@tkhala: ah, buena captura ... sería más como 'LD_PRELOAD = \' pwd \ '/a.out program_to_test' luego .... –

que suponer que el archivo a.out es un objeto compartido y no un ejecutable y seguir adelante ...

dlsym() es una función de la biblioteca libdl, que normalmente reside en el libdl.so.2 compartida objeto en los sistemas modernos de Linux.

Supongo que su objeto compartido a.out no está vinculado a libdl. Eso significa que cuando precarga en una binaria simple como uname que no atrae muchas otras librerías, libdl.so.2 no se puede extraer y se obtiene un error de símbolo indefinido.

Si, por otro lado, lo precarga a un archivo binario que está vinculado y, finalmente, extrae libdl.so.2, su objeto compartido funciona bien.

Verificaría con ldd si su propio objeto compartido está vinculado contra libdl como debería, y también qué bibliotecas son directa o indirectamente extraídas cuando se ejecutan uname y ls.

EDITAR:

Acabo de confirmar esto. La forma de corregir este error es vincular el objeto compartido con libdl. Agregar -ldl a sus LDFLAGS debería ser el truco.

Fuente

2010-12-08 07:51:44 thkala

Tenga en cuenta que -ldl puede necesitar estar antes que los otros archivos .o, p.ej"gcc -ldl -shared foo.o bar.o -o baz.so". –

No puedo comentar la respuesta aceptada, sin embargo, vale la pena mencionar aquí que uno puede encontrar el problema de no tener libdl.so.2 vinculado correctamente cuando se usa -ldl delante del comando de compilación (suponiendo que el enlace y la compilación se ejecuta con el mismo comando, esto es posible ya que las librerías LD_PRELOAD generalmente se basan en un archivo fuente).

Así que llame a gcc con -ldl al final:

gcc -shared -fPIC fakeuname.c -o libfakeuname.so -ldl

En mi caso, tener -ldl en la parte delantera dio lugar a error misma que en la pregunta:

uname: symbol lookup error: ./libfakehostname.so: undefined symbol: dlsym

Fuente

2012-10-24 09:08:37 kraju

Punto muy importante ... – user1173339

sí pulgares arriba !!! La respuesta de thkala todavía me dio un error, pero tu "-ldl" al final resolvió todo. –

¡Gracias! ¡Esto funcionó para mí! –

ajuste de Mi lib para LD_PRELOAD hace algunos procesos producen errores cargador

Respuesta

Cuestiones relacionadas