compatibilità binaria tra le distribuzioni Linux

Question

Scusate se questa è una domanda ovvia, ma ho trovato sorprendentemente pochi riferimenti sul web ...

Sto lavorando con un API scritto in C da uno dei nostri partner commerciali e fornito come file .so binary, costruito su Fedora 11. Abbiamo testato l'API su una macchina di sviluppo Fedora 11 senza problemi. Tuttavia, quando provo a collegarmi all'API sulla piattaforma di destinazione del nostro cliente, che si trova su SuSE Enterprise 10.2, ottengo un errore "Formato file non riconosciuto".

I comandi che fanno anche parte del pacchetto binutils, come objdump o nm, mi danno lo stesso errore di formato del file.

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

e le "LDD" comando spettacoli:: Il "file" di comando mi mostra

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] 

Sto indovinando questo è dovuto alla incompatibilità tra le librerie C sulle due piattaforme, con la il problema è che il codice è stato compilato con una nuova versione di glibc ecc. rispetto a quella disponibile su SuSE 10.2. Sto postando questa domanda nella remota possibilità che ci sia un modo per compilare il codice sulla piattaforma Fedora 11 del nostro partner in modo tale che possa essere eseguito anche su SuSE 10.2.

Answer 1

Penso che il trucco consista nel creare un nuovo stile di Linux con le versioni più vecchie del kernel e della libreria C di qualsiasi piattaforma che si desidera supportare. Nel mio lavoro sviluppiamo Debian 4, che ci permette di supportare ufficialmente Debian 4 e versioni successive, RedHat 3,4,5, SuSE 10 e varie altre distribuzioni (SELinux, ecc.) In modo non ufficiale.

Sospetto che basandosi su una nuova versione di Linux, diventa difficile supportare le persone su macchine precedenti.

(modifica) Devo dire che usiamo il compilatore predefinito fornito con Debian 4, che credo sia GCC 4.1.2. L'installazione di versioni più recenti del compilatore tende a rendere la compatibilità molto peggiore.

Answer 2

Windows ha problemi con la compatibilità tra diversi realease, service pack, SDK installati e DLL in generale (DLL Hell, chiunque?). Linux non è immune allo stesso tipo di problemi.

I problemi di compatibilità che ho visto sono:

• libreria runtime cambia
• libreria di collegamento cambia
• Kernel cambia
• Compiler cambiamenti tecnologici (ad esempio: pre e post versioni gcc egcs Questo potrebbe. sii il tuo problema).
• problemi Packager (RPM vs APT)

Nel vostro caso particolare, mi piacerebbe fosse fatto un "gcc -v" sul loro sistema e riferire a voi il numero di versione di gcc. Confrontalo con quello che stai usando.

Potrebbe essere necessario ottenere questa versione del compilatore per costruire la metà con.

Answer 3

Se il messaggio è formato di file non riconosciuto, il problema è molto probabilmente menzionato da elmarco in un commento, vale a dire architettura diversa. Potrebbe (non sono sicuro) essere una mancata corrispondenza della versione del linker dinamico, ma ciò significherebbe che il file .so è stato creato con un linker dinamico antico.Non credo che nessuna incompatibilità in libc possa causare questo: potrebbero causare errori di link e problemi di runtime (molto raramente), ma non questo.

Answer 4

Non so di Suse, ma so che alla fedora piace stare ai margini. Quindi potresti avere ragione sulle versioni della libreria. Perché non chiedi e vedi se riesci a ottenere il codice sorgente e costruirlo sulla tua macchina Suse?

Answer 5

È possibile utilizzare Linux Application Checker strumento ([1], [2], [3]) al fine di risolvere i problemi di compatibilità di un'applicazione tra le distribuzioni Linux. Controllerà i tuoi formati di file e tutte le librerie dipendenti. Supporta quasi tutte le distribuzioni Linux più diffuse, incluse tutte le versioni di SuSE e Fedora.

Answer 6

Questo è solo un parere personale, ma quando distribuendo qualcosa in solo binario formano su Linux, avete alcune opzioni:

1. costruire il gamut di .deb e .rpms per ogni distro sotto il sole, con un pacchetto ".tar.gz pieno di binari" nominale per tutto ciò che hai perso. La prima parte è ideale ma ingombrante. L'ultima parte vi porterà ai punti 2 e 3.

2. Fate come alcuni suggeriscono e trovate la più antica distro che potete trovare e costruire lì. La mia opinione è che questa è una specie di idea ridicola. Vedere il punto 3.

3. Distribuire i binari e collegare staticamente dove mai è possibile. Soprattutto per libstdC++, che sembra essere il tuo problema qui. Ci sono apparentemente moltissime versioni incompatibili di libstdC++ in giro, il che lo rende un incubo di compatibilità. Se non riesci a collegare in modo statico, puoi anche mettere i file * .so insieme al tuo binario e utilizzare elementi come LD_PRELOAD o LD_LIBRARY_PATH per renderli preferibilmente collegati in fase di runtime. Nota che se segui questa strada potresti dover rispettare LGPL ecc. Poiché ora stai distribuendo il lavoro di altre persone insieme al tuo progetto.

Naturalmente, la distribuzione del progetto in formato sorgente è sempre preferibile su Linux. :-)