|
|||||||
|
|
|
 |
|
|
Strumenti |
20-02-2006, 10:49
|
#1 |
|
Senior Member
Iscritto dal: Jul 2002
Messaggi: 869
|
creazione file oggetto (librerie dinamiche)
c'è un modo per risolvere gli errori generati dalle librerie dinamiche quando si cerca di eseguire su una distribuzione di linux (A) un file eseguibile creato con un'altra distribuzione (B)? E' possibile magari creare un file oggetto su B che contenga tutte le librerie necessarie per far girare il programma e poi magari compilare solo l'oggetto su A? Grazie per l'aiuto.
|
|
|
|
20-02-2006, 11:38
|
#2 | ||
|
Senior Member
Iscritto dal: Jan 2006
Messaggi: 2722
|
Quote:
 ). Ovviamente la versione delle librerie deve essere "compatibile" (stessa versione o superiore). Non è importante la posizione delle librerie in (A) e (B), dal momento che su Linux tramite il comando "ldconfig" si indica al linker del SO dove reperire le librerie (le cui directory sono specificate /etc/ld.so.conf). Tale comando viene lanciato automaticamente ogni volta che si installa una nuova libreria (a mano o con rpm) quindi non devi normalmente preoccuparti di farlo a mano, era solo per spiegare  Quote:
Al peggio compili tutto in modo statico, così da "inglobare" le librerie richieste nell'eseguibile (esso diventa più grosso in termini di spazio occupato su disco, ma non ti crea problemi di dipendenze) - esempio di programma compilato in modo statico è Firefox se non erro.Tornando alla tua idea, non ti pare più semplice installare le librerie richieste dal programma anche su (A), se su questo sistema non sono presenti?
__________________
- Spesso gli errori sono solo i passi intermedi che portano al fallimento totale. - A volte penso che la prova piu' sicura che esiste da qualche parte una forma di vita intelligente e' il fatto che non ha mai tentato di mettersi in contatto con noi. -- Bill Watterson |
||
|
|
|
|
21-02-2006, 17:08
|
#3 |
|
Senior Member
Iscritto dal: Jul 2002
Messaggi: 869
|
Il problema è che il codice compilato con le librerie di A mi da degli ottimi risultati. Lo stesso codice compilato su macchine con un compilatore differente (superiore) anche con la stessa distribuzione mi da risultati peggiori (il che di per se sembra assurdo, magari la gestione dei numeri casuali cambia il comportamento dell'algoritmo). Quindi per risolvere il problema l'idea è di creare un eseguibile in cui includere tutte le librerie che gli piacciono tanto ( per la cronaca lavoro sulla suse 9) per far si che il codice eseguito poi su qualsiasi distribuzione si comporti sempre allo stesso modo. A tal fine la tua idea di compilare tutto in modo statico mi sembra la soluzione ai miei problemi. come si fa? e soprattutto come faccio a sapere quali sono le librerie dinamiche eventualmente da linkare nell'eseguibile? Grazie per l'aiuto fidel.
|
|
|
|
|
21-02-2006, 17:17
|
#4 |
|
Senior Member
Iscritto dal: Apr 2000
Città: Roma
Messaggi: 15625
|
Ci sono diversi modi per risolvere il problema, non solo la compilazione statica.
Un modo potrebbe essere di decidere una directory di installazione per il tuo programma (ad es. /opt/myprog), e portarsi dietro le librerie dinamiche necessarie. Quindi l'eseguibile deve essere linkato in modo da cercare in primis nella directory di installazione (si fa con -Wl,--rpath=/opt/myprog). Altre soluzioni passano per LD_LIBRARY_PATH, LD_PRELOAD, ecc. (oltre al link statico).
__________________
0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12 |
|
|
|
|
21-02-2006, 18:47
|
#5 | |
|
Senior Member
Iscritto dal: Jan 2006
Messaggi: 2722
|
Quote:
I passi che eseguirei sono quindi: 1) modifica della variabile d'ambiente LD_LIBRARY_PATH in modo tale che la prima directory elencata sia /opt/myprog 2) lancio "ldconfig -n /opt/myprog" (oppure aggiungo /opt/myprog in /etc/ld.so.conf e lancio semplicemente "ldconfig" (questo ovviamente può essere fatto automaticamente nella fase "post" di un'installazione da rpm)
__________________
- Spesso gli errori sono solo i passi intermedi che portano al fallimento totale. - A volte penso che la prova piu' sicura che esiste da qualche parte una forma di vita intelligente e' il fatto che non ha mai tentato di mettersi in contatto con noi. -- Bill Watterson |
|
|
|
|
|
21-02-2006, 18:57
|
#6 | ||
|
Senior Member
Iscritto dal: Jan 2006
Messaggi: 2722
|
Quote:
1) i sorgenti delle librerie che il programma usa (se stai usando librerie installate tramite rpm ti basta avere normalmente il pacchetto -devel corrispondente per ciascuna libreria. L'unica eccezione che ricordo sono le librerie Qt, che ha due pacchetti diversi, il -devel che contiene solo gli header, ed il -devel-static che appunto contiene anche i sorgenti per eseguire una compilazione statica). Se qualcosa fallisce, installa la libreria compilandola dai sorgenti e stai tranquillo, ma con i pacchetti -devel personalmente non ho avuto mai dispiaceri. 2) passare al gcc l'opzione --static Quindi è molto semplice, anche se avrai poi un eseguibile di dimensioni più ampie (in proporzione alla dimensione delle librerie). Dimenticavo, per conoscere QUALI librerie il programma usa, devi lanciare il comando ldd nome_eseguibile sul programma linkato dinamicamente. Ti consiglio però se non vuoi impazzire (nel caso vuoi compilare staticamente programmi tipo amarok...) di andare sul sito web dell'applicazione e vedere da lì le dipendenze richieste. Devi necessariamente avere le mandatory dependencies (senza quelle librerie il programma non compila) ed a tua discrezione le librerie opzionali a seconda delle funzionalità aggiuntive che vuoi avere. EDIT 1: Ah, se vuoi compilare staticamente programmi che sono forniti del file configure (quelli che compili con ./configure && make && make install per intenderci, in pratica tutti) e quindi non controlli direttamente il gcc, invece di quello che ho detto al punto 2), lanci semplicemente ./configure --enable-static così che il make compilerà le librerie in modo statico. Normalmente l'opzione --enable-static di configure ti permette anche di specificare QUALI librerie compilare staticamente e quali no (se non specifichi nulla, il make tenterà di compilare staticamente tutte le librerie richieste). EDIT 2: Poi non ho capito una cosa: Quote:
Ho visto persone che "giocavano" con gli eseguibili linkati dinamicamente senza sapere neanche l'esistenza di ldconfig su suse
__________________
- Spesso gli errori sono solo i passi intermedi che portano al fallimento totale. - A volte penso che la prova piu' sicura che esiste da qualche parte una forma di vita intelligente e' il fatto che non ha mai tentato di mettersi in contatto con noi. -- Bill Watterson Ultima modifica di -fidel- : 21-02-2006 alle 19:28. |
||
|
|
|
|
21-02-2006, 19:12
|
#7 | |
|
Senior Member
Iscritto dal: Jan 2006
Messaggi: 2722
|
Dimenticavo:
Quote:
): come pero' succede con Windows (ma anche con la compilazione statica), il pacchetto di installazione ti diventa in media 8-10 volte più grosso, però effettivamente non hai più problemi di dipendenze (cosa che un po' fa dannare gli utenti linux alle prime armi, vista la mole e la velocità di uscita di nuove release delle librerie in ambiente linux).
__________________
- Spesso gli errori sono solo i passi intermedi che portano al fallimento totale. - A volte penso che la prova piu' sicura che esiste da qualche parte una forma di vita intelligente e' il fatto che non ha mai tentato di mettersi in contatto con noi. -- Bill Watterson |
|
|
|
|
|
22-02-2006, 09:27
|
#8 | ||
|
Senior Member
Iscritto dal: Apr 2000
Città: Roma
Messaggi: 15625
|
Quote:
Nota che non è necessario utilizzare ld.so.conf, basta LD_LIBRARY_PATH. Quote:
Nota che puoi anche usare --rpath per specificare una directory relativa (ad es. ../my/lib), ma è relativa alla directory di lancio del programma e non a quella in cui risiede il programma. Anche qui, occorre uno script che modifichi la directory corrente con quella del programma affinché --rpath abbia l'effetto desiderato.
__________________
0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12 |
||
|
|
|
|
22-02-2006, 10:33
|
#9 | ||
|
Senior Member
Iscritto dal: Jan 2006
Messaggi: 2722
|
Quote:
Quote:
__________________
- Spesso gli errori sono solo i passi intermedi che portano al fallimento totale. - A volte penso che la prova piu' sicura che esiste da qualche parte una forma di vita intelligente e' il fatto che non ha mai tentato di mettersi in contatto con noi. -- Bill Watterson |
||
|
|
|
|
22-02-2006, 11:09
|
#10 | ||
|
Senior Member
Iscritto dal: Apr 2000
Città: Roma
Messaggi: 15625
|
Quote:
Su alcuni programmi il trucco di LD_LIBRARY_PATH o LD_PRELOAD non può funzionare per ovvi motivi di sicurezza (ad es. per i programmi suid). Quote:
__________________
0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12 |
||
|
|
|
|
22-02-2006, 11:12
|
#11 | ||
|
Senior Member
Iscritto dal: Jan 2006
Messaggi: 2722
|
Quote:
Quote:
Con il "metodo" --rpath meglio creare un piccolo script allora...
__________________
- Spesso gli errori sono solo i passi intermedi che portano al fallimento totale. - A volte penso che la prova piu' sicura che esiste da qualche parte una forma di vita intelligente e' il fatto che non ha mai tentato di mettersi in contatto con noi. -- Bill Watterson Ultima modifica di -fidel- : 22-02-2006 alle 11:15. |
||
|
|
|
|
|
| Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 18:47.
