2009-11-20 21 views
6

Lo siento si esto es una pregunta obvia, pero he encontrado sorprendentemente pocas referencias en la web ...compatibilidad binaria entre las distribuciones de Linux

Estoy trabajando con una API escrita en C por uno de nuestros socios de negocios y se nos suministró como un archivo binario .so, basado en Fedora 11. Hemos estado probando la API en una máquina de desarrollo Fedora 11 sin problemas. Sin embargo, cuando intento vincularme con la API en la plataforma de destino de nuestro cliente, que es SuSE Enterprise 10.2, aparece el error "No se reconoce el formato del archivo".

comandos que son también parte del paquete binutils, tales como objdump o nm, me da el mismo error de formato de archivo.

ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped 

y los "LDD" espectáculos de comando:: El "archivo" de comandos me muestra

ldd: warning: you do not have execution permission for `./libuscuavactivity.so.1.1' 
./libuscuavactivity.so.1.1: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./libuscuavactivity.so.1.1) 
[dependent library list] 

supongo esto es debido a la incompatibilidad entre las bibliotecas de C en las dos plataformas, con el El problema es que el código se compiló con una nueva versión de glibc, etc. que la disponible en SuSE 10.2. Estoy publicando esta pregunta sobre la posibilidad de que haya una forma de compilar el código en la plataforma Fedora 11 de nuestro socio de tal manera que también se ejecute en SuSE 10.2.

+2

en la misma arquitectura? (i386! = amd64) – elmarco

+0

Debería haber mencionado que la plataforma de compilación y la plataforma SuSE 10.2 de destino son ambas x86_64. –

+0

Inspecciona el formato de archivo con objdump o simplemente ejecutando el .so (sí, esto es posible). Será ELF, porque se usa desde la edad de piedra. Si tiene una versión incompatible de libc, recibirá un mensaje de error que dice exactamente eso, por lo que su conjetura probablemente sea incorrecta y el problema probablemente sea diferente. – hirschhornsalz

Respuesta

4

Creo que el truco es construir en una distribución de Linux con el núcleo más antiguo y versiones de la biblioteca C de cualquiera de las plataformas que desea apoyar. En mi trabajo, nos basamos en Debian 4, que nos permite dar soporte oficialmente a Debian 4 y superior, RedHat 3,4,5, SuSE 10 y varias otras distribuciones (SELinux, etc.) de manera no oficial.

Sospecho mediante la construcción de una buena nueva versión de Linux, se hace difícil apoyar a las personas en máquinas más antiguas.

(editar) Debo mencionar que usamos el compilador por defecto que viene con Debian 4, que creo que es GCC 4.1.2. La instalación de versiones de compilador más nuevas tiende a empeorar la compatibilidad.

3

de Windows tiene problemas con la compatibilidad entre los diferentes realeases, paquetes de servicios, SDK instalados, y las DLL en general (DLL Infierno, alguien?). Linux no es inmune a los mismos tipos de problemas.

Los problemas de compatibilidad que he visto incluyen:

  • biblioteca de tiempo de ejecución cambia
  • librería de enlace cambia
  • kernel cambia
  • cambios tecnología de compilación (por ejemplo: pre y post versiones de gcc EGCS Esta fuerza. se tu problema).
  • cuestiones Packager (RPM vs APT)

En su caso particular, tendría que hacer un "gcc -v" en su sistema e informan a que el número de versión de gcc. Compara eso con lo que estás usando.

Es posible que tenga que conseguir esa versión del compilador para construir su mitad.

1

Si el mensaje es un formato de archivo no reconocido, entonces el problema probablemente sea uno mencionado por elmarco en un comentario, es decir, una arquitectura diferente. Podría (no estoy seguro) ser un desajuste de la versión del enlazador dinámico, pero eso significaría que el archivo .so se construyó con un antiguo enlazador dinámico.No creo que ninguna incompatibilidad en libc pueda causar esto, podrían causar fallas en los enlaces y problemas de tiempo de ejecución (muy raramente), pero esto no es así.

0

No sé de Suse, pero sé que a Fedora le gusta estar al borde de la hemorragia. Por lo que es posible que tenga razón sobre las versiones de la biblioteca. ¿Por qué no preguntas y ves si puedes obtener el código fuente y compilarlo en tu máquina Suse?

3

Puede utilizar de aplicaciones Linux inspector herramienta ([1], [2], [3]) con el fin de resolver los problemas de compatibilidad de una aplicación entre las distribuciones de Linux. Verificará sus formatos de archivo y todas las bibliotecas dependientes. Es compatible con casi todas las distribuciones populares de Linux, incluidas todas las versiones de SuSE y Fedora.

enter image description here

2

Ésta es sólo una opinión personal, pero cuando algo en la distribución de la que sólo se forman en Linux, usted tiene algunas opciones:

  1. construir el espectro de .debs y .rpms para cada distribución bajo el sol, con un paquete nominal ".tar.gz lleno de binarios" para cualquier cosa que te hayas perdido. La primera parte es ideal pero engorrosa. La última parte lo llevará al punto 2 y 3.

  2. Haga lo que algunos sugieren y encuentre la distribución más antigua que pueda encontrar y construir allí. Mi propia opinión es que esta es una especie de idea ridícula. Consulte el punto 3.

  3. Distribuya los binarios, y establezca el enlace siempre que pueda. Especialmente para libstdC++, que parece ser su problema aquí. Aparentemente hay muchas versiones incompatibles de libstdC++ flotando alrededor, lo que la convierte en una pesadilla de compatibilidad. Si no puede establecer un vínculo estático, también puede colocar archivos * .so junto a su archivo binario y usar elementos como LD_PRELOAD o LD_LIBRARY_PATH para hacer que se vinculen preferentemente en el tiempo de ejecución. Tenga en cuenta que si toma esta ruta puede que tenga que cumplir con LGPL, etc. ya que ahora está distribuyendo el trabajo de otras personas junto con su proyecto.

Por supuesto, siempre se prefiere distribuir su proyecto en formato fuente en Linux. :-)

Cuestiones relacionadas