linux - libresolv - Cargando múltiples bibliotecas compartidas con diferentes versiones

error while loading shared libraries libresolv so 2

Question

Tengo un ejecutable en Linux que carga libfoo.so.1 (que es un SONAME ) como una de sus dependencias (a través de otra biblioteca compartida). También se vincula a otra biblioteca del sistema, que, a su vez, se vincula a una versión del sistema , libfoo.so.2 . Como resultado, tanto libfoo.so.1 como libfoo.so.2 se cargan durante la ejecución, y el código que se suponía debía invocar funciones de la biblioteca con la versión 1 termina llamando funciones (incompatibles con binarios) de una biblioteca de sistema más nueva con versión 2, porque algunos símbolos permanecen iguales. El resultado es generalmente un aplastamiento de pila y una segfault posterior.

Ahora, la biblioteca que enlaza con la versión anterior es una biblioteca de código fuente de terceros, y no puedo controlar en qué versión de libfoo compila. Asumiendo eso, la única opción restante es reconstruir un grupo de bibliotecas del sistema que actualmente enlazan con libfoo.so.2 para vincular con libfoo.so.1 .

¿Hay alguna forma de evitar reemplazar las bibliotecas del sistema con copias locales que se vinculen con libfoo anterior? ¿Puedo cargar ambas bibliotecas y tener el código llamando a la versión correcta de los símbolos? ¿Entonces necesito un control de versiones especial a nivel de símbolo?

Answer 1

Es posible que pueda hacer algunos trucos de script de versión:

http://sunsite.ualberta.ca/Documentation/Gnu/binutils-2.9.1/html_node/ld_26.html

Esto puede requerir que escriba un contenedor alrededor de su lib que atrae libfoo.so.1 que exporta algunos símbolos explícitamente y enmascara a todos los demás como locales. Por ejemplo:

MYSYMS {global: foo1; foo2; local: *; };

y usa esto cuando vincula ese contenedor como:

gcc -shared -Wl, -script-script, mysyms.map -o mylib wrapper.o -lfoo -L / path / to / foo.so.1

Esto debería hacer que los símbolos de libfoo.so.1 sean locales al wrapper y no estén disponibles para el exe principal.

Answer 2

Solo puedo pensar en una solución alternativa. Lo cual sería vincular estáticamente una versión de la "biblioteca del sistema" que está utilizando. Para su compilación estática, puede hacer que enlace contra la misma versión anterior que la biblioteca de terceros. Dado que no se basa en la versión más nueva ...

Quizás también es posible evitar estos problemas al no vincular a la biblioteca de terceros de la forma habitual. En cambio, su programa podría cargarlo en el momento de la ejecución. Quizás entonces podría oscurecerse contra el resto. Pero no sé mucho sobre eso.