¿Cómo funcionan las bibliotecas compartidas en un sistema mixto de 64 bits/32 bits?

Question

Buenos días,

en una caja RedHat de 64 bits tenemos que compilar y ejecutar una aplicación de 32 bits. Mientras tanto, pude compilar la versión de gcc necesaria (4.0.3) y todas las bibliotecas de tiempo de ejecución requeridas en 32 bits y establecí LD_LIBRARY_PATH para apuntar a las versiones de 32 bits, pero ahora, durante el proceso de compilación restante, debe ejecutarse un pequeño programa Java que está instalado en/usr/bin como un programa de 64 bits, que ahora encuentra la versión de 32 bits de libgcc_s.so primero.

En general, si configuro LD_LIBRARY_PATH para las versiones de 32 bits, rompo los programas de 64 bits y viceversa.

¿Cómo se supone que funciona? Estoy seguro de que no soy la primera persona con este problema. ¿Cómo se resuelve generalmente?

Saludos, Stefan

Answer 1

Como solución, envuelven la llamada Java en un pequeño script de shell, que unset s LD_LIBRARY_PATH y luego llama al ejecutable. Alternativamente, esto también podría funcionar:

LD_LIBRARY_PATH= java... 

Tenga en cuenta el espacio entre "=" y el nombre del ejecutable.

Answer 2

En Solaris se puede usar LD_LIBRARY32_PATH y LD_LIBRARY64_PATH, pero eso no es compatible con Linux.

En general, se debe simplemente nunca necesita para establecer LD_LIBRARY_PATH en absoluto en el primer lugar:

• o bien instalar librerías necesarias en /usr/lib32 o /usr/lib64 como apropiado, o
• construir su 32 aplicación de bits con -Wl,-rpath=/path/to/32-bit/libs

Answer 3

Acaba de configurar LD_LIBRARY_PATH en ambas rutas (use dos puntos para delimitar). El enlazador ignorará las bibliotecas que no puede leer.

Answer 4

Me he enfrentado exactamente este mismo problema al remasterizar un sistema tinycore64 de 32 bits que ejecuta un kernel de 64 bits.

Después de mucha búsqueda, he descubierto por qué estos comentarios tendrían sentido para ambos. .

"Eso estaría bien, pero - por lo menos en mi entorno - no parecen funcionar El cargador se quejó, sino que no se limitó a saltar las bibliotecas que no coinciden con el bit-dad. ¡Tristemente!" - struppi

"Esto es muy extraño, ¿podrías describir cómo fallaron las cosas? Además, ¿quizás publique la salida de ldd?" - Adam Goode

Y por qué este comentario puede parecer cierto, pero en realidad es incorrecto.

El vinculador ignorará las bibliotecas que no puede leer.

Este enlace arroja algo de luz sobre él. http://www.markusbe.com/2009/09/about-running-32-bit-programs-on-64-bit-ubuntu-and-shared-libraries/

Y más al punto, usted encontrará la página de ld.so esclarecedora.

Resulta que el nombre de ruta puede hacer una diferencia en lo que el enlazador en tiempo de ejecución ld.so elige como la biblioteca que cargará. En mi sistema Linux de 64 bits, tengo una gama de nombres de directorio extraños además de los estándar. p.ej./lib/x86_64-linux-gnu. De hecho, pensé que experimentaría moviendo las bibliotecas en esa ruta a/lib64. Cuando lo hice, ¿adivinen qué pasó? de repente mi aplicación de 64 bits (brctl en este caso) no funcionó y se quejó con "clase ELF incorrecta". Hola ... ahora estamos en algo.

Ahora no estoy 100% seguro pero la clave parece estar relacionada con la expansión del token rpath. Sospecho que la expansión de $ {PLATAFORMA} puede tener algo que ver con eso. Y el nombre x86_64 debe ser parte de eso.

En cualquier caso, cuando puse mis librerías de 64 bits en las vías de acceso de biblioteca denominadas x86_64-linux-gnu como apposed a solo lib64, se prefirieron a las de 32 bits y funcionó.

En su caso, es probable que desee hacer algo muy similar para las bibliotecas de 32 bits en 64. Pruebe i386-linux-gnu.

Así que en mi caso que voy a instalar las bibliotecas de 64 bits compartida en un espacio de usuario de 32 bits, he creado las siguientes rutas:

mkdir /lib/x86_64-linux-gnu/ 
mkdir /usr/lib/x86_64-linux-gnu/ 
ln -s /lib/x86_64-linux-gnu /lib64 
ln -s /usr/lib/x86_64-linux-gnu /usr/lib64 

añadir sus bibliotecas de 64 bits a las trayectorias de 64 bits y bibliotecas de 32 bits a la de 32 bits/lib &/usr/lib paths only.

A continuación, agregue las rutas específicas de 64 bits a ld.so.conf y actualice su caché con ldconfig Ahora sus aplicaciones de 32 bits & de 64 bits se ejecutarán sin problemas.

Answer 5

Agregue ambos los directorios de 32 bits y 64 bits a LD_LIBRARY_PATH.

Si hace esto, entonces ld.so para 32 bits o 64 bits utilizará las bibliotecas correctas.

p. Ej. Una aplicación de prueba de 32 bits "test32" y una "prueba" de aplicación de prueba de 64 bits, con una copia localmente instalada de una versión más nueva de gcc y binutils en un usuario homedir, para evitar dañar la instalación de gcc en todo el sistema :

 
=> export LD_LIBRARY_PATH=/home/user1/pub/gcc+binutils/lib:/home/user1/pub/gcc+binutils/lib64 

=> ldd ./test32 
    libstdc++.so.6 => /home/user1/pub/gcc+binutils/lib/libstdc++.so.6 (0x00111000) 
    libgcc_s.so.1 => /home/user1/pub/gcc+binutils/lib/libgcc_s.so.1 (0x00221000) 

=> ldd ./test 
    libstdc++.so.6 => /home/user1/pub/gcc+binutils/lib64/libstdc++.so.6 (0x00007ffff7cfc000) 
    libgcc_s.so.1 => /home/user1/pub/gcc+binutils/lib64/libgcc_s.so.1 (0x00007ffff7ad2000) 

(rutas de bibliotecas interesantes menos eliminados)

esto demuestra que los cargadores saben hacer caso omiso de las bibliotecas de la arquitectura mal, al menos en este sistema Scientific Linux 6.3 (derivado de RHEL). Esperaría que otras distros funcionaran de manera similar, pero no han probado esto.

Sin embargo, es posible que esto haya comenzado a ser el caso más recientemente que su versión de distribución (no especificada).