Newsgroup: it.comp.os.linux.iniziare
Titolo: Copiare dipendenze

Ciao,
 
con il comando ldd posso sapere quali librerie servono a un eseguibile.
Mi piacerebbe riuscire a:
 
1) copiare tutti i file restituiti da ldd in una cartella
2) copiare tutti i file restituiti da ldd tramite ssh in un altro pc 
mantenendo i percorsi
 
Immagino sia banale ma non sono pratico delle magie della shell :)
Marco

 mantenendo i percorsi
 
ldd .... > lista.file.txt
man  rsync
 
 

 mantenendo i percorsi
 
ldd .... > lista.file.txt
man  rsync
 
 
Pensa bene a quello che fai. Se il tuo scopo è installare un 
programma o delle librerie su un altro computer faresti bene 
a procurarti il pacchetto di quel programma (e di tutte le 
librerie necessarie) ed installare tutto con gli strumenti della 
distribuzione che usi.

 distribuzione che usi.
 
 
Il pacchetto non esiste perché il programma lo scrivo io.
Per quanto riguarda le librerie sono le Qt4, le SDL e alcune 
proprietarie di schede aggiuntive.
 
Ciao e grazie
Marco

 proprietarie di schede aggiuntive.
 
1) se il programma lo scrivi tu sai quali librerie  stai usando e ldd
    non ti serve ad un cacio.
2) ti scarichi i pacchetti, in versione .devel, di QT4, SDL e li installi
   con gli strumenti della tua distribuzione.
3) installi i driver delle schede aggiuntive e ti procuri gli header.
4) ti documenti su come fare un pacchetto 
 
 
 

 percorsi
[...]
*cde*
- 
http://www.stanford.edu/~pgbovine/cde.html
 
 
lo fa in automatico
-- 
Puppy Linux wiki:  
http://dokupuppylinux.tk
 
Puppy Linux Forum: 
http://www.italianpuppy.org/
 
Windows me genuit, Ubuntu rapuere / tenet nunc Puppy Linux...
invito dropbox 2GB free - 
http://db.tt/Vc6IeN4
 

 4) ti documenti su come fare un pacchetto
 
 
Ok, ma la strada breve:
 
1) copiare tutte le librerie nello stesso percorso dell'eseguibile
 
Non è:
 
a) più pulita: non sono sparse per il sistema
b) più semplice: basta scompattare uno zip e il software parte senza 
dover ripetere i punti 1..4 ogni volta, magari anche da personale non 
esperto
c) più flessibile: se modifico una libreria non devo rifare daccapo il 
pacchetto
d) più tollerante: se avessi più versioni della stessa libreria ognuna 
risiede presso il proprio eseguibile senza interferire con le altre versioni
 
Ti sarei grato se commentassi questi punti che a mio avviso sono 
vantaggiosi.
 
Grazie
Marco
 

 lo fa in automatico
 
 
Grazie, ci do un'occhiata.
 
Marco

 a) più pulita: non sono sparse per il sistema
No.
Se per la libxyz.2_14.1 esce un aggiornamento che ripara un baco che
porterebbe all'esplosione nucleare del processore il prossimo sabato
se non aggiorni alla 2_14.2, avere dieci versioni della libreria che
sono sparse per il sistema a me non sembra per nulla pulito.
Mentre avere le librerie al loro posto istituzionale, in copia unica
mi sembra più vantaggioso.
 
Certo, c'è da imparare come si fa un pacchetto.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net
 

 mi sembra più vantaggioso.
 
 
Uhm... sono quasi convinto ma non del tutto :)
 
Cioè, stiamo parlando di librerie di terze parti, non di sistema (per 
cui vale il discorso dell'esplosione nucleare).
 
Nella mia (piccola) esperienza, sotto windows, ho notato che gli 
aggiornamenti delle librerie al posto istituzionale causano spesso 
malfunzionamenti nei vari programmi perché compilati con quella versione 
specifica. Occorre quindi aggiornare il software anche se il tutto era 
perfettamente funzionante.
 
Invece se le librerie sono agganciate all'eseguibile posso decidere di 
aggiornarle oppure lasciare che il software continui a fare il suo 
lavoro senza problemi.
 
Questo è particolarmente vero per programmi a lunga scadenza. Esempio: 
ho in giro alcuni script python vecchi di diversi anni. Però ho 
consegnato al cliente non solo lo script ma anche tutti i pacchetti di 
installazione delle librerie di allora (numpy, pyqt, pyqwt ecc...)
 
Se aggiornassi le librerie, non funzionerebbe più una cippa...
 
Marco
 
 
Marco
 
 

 Non si può, Linux non ha cartelle, solo directory.
Io l'ho scritto una volta e a momenti mi mazzano :-)
 
 
-- 
Il problema del capitalismo è che il padrone è troppo ingordo.

 Se aggiornassi le librerie, non funzionerebbe più una cippa...
 
Ma se non le aggiorni, sei esposto ad una marea di problemi, anche
di sicurezza, che riguardano la TUA versione di python, e che sono
invece stati corretti dal resto del mondo.
 
Se non sai come costruire un pacchetto che si autocompili/installi
con le librerie corrette che trova sul sistema non è colpa mia. ;-)


 con le librerie corrette che trova sul sistema non è colpa mia. ;-)
 
 
Questo è un altro discorso. Non sto dicendo che sia colpa tua.
Soltanto lo trovo macchinoso, soprattutto durante lo sviluppo.
 
Ma se è questa la prassi... mi adeguerò.
 
Marco
 

 Questo è un altro discorso. Non sto dicendo che sia colpa tua.
 
Ehi, io lo smiley ce lo avevo messo.
 
Comunque, tornando serio, sì, può essere macchinoso, ma ti eleva dal
ciabattaio al rango di sviluppatore. :-)
 
 
PS: ammiro molto i ciabattai, a parte quando si mettono a programmare
sistemi operativi, o componenti degli stessi.


 risiede presso il proprio eseguibile senza interferire con le altre versioni
 
No, perche` la gestione delle librerie tende a risolvere anche questo problema 
(e.g. la creazione di symlink per la libreria che permettano di richiamarla non 
solo tramite il nome generico, ma anche con il numero di versione che 
utilizziamo).
 
Detto questo, se proprio vuoi continuare per questa strada (sconsigliato), 
studia come fare un binario statico, altrimenti crea un pacchetto (rpm o deb) in 
cui sono elencate tutte le dipendenze utilizzate dal tuo applicativo
 
Enrico

 cui sono elencate tutte le dipendenze utilizzate dal tuo applicativo
 
 
Ovviamente non seguirò questa strada. Posso avere idee sbagliate ma se 
riconosco che lo sono non persevero certo!
 
Mi metto a studiare come fare un pacchetto!
Ultimissima domanda, giusto per capire se ho capito:
 
attualmente sto scrivendo 'sto programmino che andrà eseguito su una 
scheda embedded, e devo per forza eseguirlo lì (durante lo sviluppo 
intendo) perché ha l'hw necessario al funzionamento.
 
Quindi dalla macchina di sviluppo compilo e poi trasferisco via ssh.
Posso dunque creare inizialmente il pacchetto deb per installare tutte 
le librerie e poi ad ogni compilazione aggiorno solo l'eseguibile senza 
dover ripetere tutta la faccenda?
 
Grazie!
Marco
 

 dover ripetere tutta la faccenda?
 
Si, ma non ti conviene, ovvero lo sforzo di preparare il pacchetto c'e` 
veramente solo la prima volta, per le successive basta riciclare le parti che 
hai gia` fatto
 
Enrico

 interferire con le altre versioni
 
  Questo sarebbe, secondo me, l'unico vantaggio.  Ti ripareresti da
possibili evoluzioni di librerie di sistema che le renderebbero
incompatibili con le versioni precedenti (cosa che in teoria non
dovrebbe succedere ma che invece è successa - e continua a succedere -
tante volte).  Di contro ti devi prendere carico anche dell'evoluzione
delle librerie, non del solo pacchetto.  In sostanza, o ti esponi a
dover aggiornare il tuo applicativo anche per stare al passo con
l'evoluzione delle librerie esterne che lui usa, sviluppate da terzi,
oppure ti prendi carico dello sviluppo e della manutenzione anche delle
librerie che utilizza.
 
  Puoi scegliere di cosa soffrire, ma non di non soffrire.
 
 
  Ciao,
 
 
-- 
Alessandro Selli 
http://alessandro.route-add.net
 
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.

 librerie che utilizza.
 
 
Chiarissimo, era quello che cercavo di dire.
Nel mio caso non si tratta di "grande distribuzione" ma di poche 
macchine specifiche con tempi di vita molto lunghi (anni) sempre 
disconnesse dalla rete.
Può però succedere che dopo x anni (v. l'esempio di python che dicevo 
prima) venga sostituito l'hardware o mi chiedano modifiche.
Se nel frattempo ho aggiornato la macchina di sviluppo o viceversa sul 
nuovo hw viene installato un s.o. più aggiornato si può manifestare il 
problema, costringendomi a dover mettere mano a codice già collaudato e 
"venduto" solo per ripristinare la compatibilità con le librerie.
 
Ti ringrazio dell'intervento, molto preciso e chiarificatore.
Marco
 

 dover ripetere tutta la faccenda?
 
Se vuoi usare le librerie statiche come ti ha suggerito Enrico devi per 
forza copiare tutto il pacchetto con tutte le librerie tutte le volte.
Se invece opti per la soluzione "standard" delle librerie dinamiche, come 
hai detto tu è sufficiente che installi una sola volta le librerie e in 
seguito ti limiti a copiare il tuo pacchettino.
 
Nicola.
 
-- 
chi va pian va san e va lontan

 Se vuoi usare le librerie statiche
[...]
????
 
non è così: le librerie STATICHE sono compilate STATICAMENTE perché poi il 
programma che necessita di queste LIBRERIE, possa essere COMPILATO 
INCLUDENDOLE nell'eseguibile finale (dopodiché le librerie statiche si 
BUTTANO VIA)
 
esempio:
 
voglio compilare imagemagick con il supporto al formato jpeg 2000
 
ma senza dover obbligare me o altri ad installare libjasper (od openjpeg)
 
cosa faccio?
 
prendo il codice sorgente di libjasper
 
./configure --prefix=/usr --enable-static --disable-shared
 
ed otterrò una libreria statica che sarà usata dal makefile di imagemagick 
che INCLUDERÀ al suo interno questa libreria 
 
infatti se darai
 
ldd `which convert`
 
ad esempio, vedrai che libjasper non è listata, essendo integrata e fusa 
nell'eseguibile finale
 
così però ho il supporto STATICO SOLO per libjasper. se volessi 
STATICHIFICARE tutto imagemagick dovrei compilare tutte le dipendenze 
STATICAMENTE prima e poi compilarvi imagemagick
 
una fatica MOSTRUOSA!
 
oppure potrei usare, sull'eseguibile finale linkato dinamicamente
 
*statifier*
-  
statifier.sourceforge.net/statifier/related_projects.html
 
 
comprare una licenza di 
 
*magicermine*
- 
http://magicermine.com/sesl.html
 
 
o utilizzare
 
*cde*
- 
www.stanford.edu/~pgbovine/cde.html
 
 
senza nessuna garanzia di successo (per tutti e tre) ed il problema (per i 
primi due) di accrescere paurosamente le dimensioni dell'eseguibile
 
*cde* non ha questo problema, nasce per *portabilizzare* le applicazioni 
linux in modo da funzionare in maniera indipendehte dall'ambiente desktop 
e dalla distribuzione, poiché copia in una cartella strutturata tutte le 
dipendenze e crea uno script per lanciare l'applicazione senza effettuare 
chiamate alle librerie di sistema, ma da quelle che ha copiato nel suo 
albero
 
è in sostanza l'evoluzione dello script che, ad esempio, mi sono scritto 
io per poter usare le ultime versioni di Seamonkey in Puppy Linux 3.01
 
a partire dalla serie (2.1?), Seamonkey richiede
 
libgcc_s.so.1: version `GCC_4.2.0'
 
ma la versione gcc di puppy linux 3.01 è 4.1.2
 
se io tentassi di copiare libgcc_s.so.1: version `GCC_4.2.0' (da Ubuntu 
Hardy ad esempio - vedi che alla fine Ubuntu serve a qualcosa), APRITI 
CIELO! succederebbero cose turche nel sistema
 
allora che fo?
 
scompatto l'archivio deb dove più mi piace e prima di lanciare quella 
versione di Seamonkey dico:
 
LD_PRELOAD=/dove/mi/piace/libgcc_s.so.1 seamonkey
 
così non creo interferenze con le librerie di sistema. CDE lavora in modo 
analogo, ma più sviluppato e automatizzato


 seguito ti limiti a copiare il tuo pacchettino.
 
 
No no, tutto a librerie dinamiche, anche per questioni di licenza.
Marco
 

 BUTTANO VIA)
 
Si è così mi sono espresso male io. Il senso era che se uno usa le librerie 
statiche fa un pacchettone tutte le volte.
Poi non ho mai indagato sul fatto se ld copy l'intera libreria o solo le 
funzioni utilizzate.


 ...
 
Vedo che ti hanno già risposto esaurientemente. Però noto che stai
sviluppando per un dispositivo embedded; le cose cambiano molto 
poiché potresti non avere un sistema operativo completo o potresti
non avere affatto un sistema operativo; per te sviluppare un pac_
chetto poterebbe non essere necessario, al limite potresti mettere 
tutto in una tarball. Poco importa, cambino i dettagli ma fondamenti 
restano gli stessi: 
 - copi tutte le librerie e i driver sul tuo dispositivo.
 - compili e copi il tuo programma sul dispositivo.
 - quando effettui cambi o prove compili il programma sul tuo 
    computer e poi copi solo questo e non tocchi il resto.
Comunque non conoscendo il tuo  dispositivo non si può dire altro
che sia significativo (e non è neanche questo il posto per chiedere).
 

 ...
 
Sarebbe stupido: usi le DDL, pardon librerie condivise, per risparmiare
memoria (sia RAM che di massa) e poi permetti n librerie (con n>>1).
 

 memoria (sia RAM che di massa) e poi permetti n librerie (con n>>1).
 
  Si, ogni scelta ha i suoi pro ei suoi contro.  A volte le scelte degli
sviluppatori vanno contro la filosofia degli amministratori di sistema e
viceversa.  Il caso di Marco è quello classico in cui si sceglie di
compilare staticamente un programma, ma scrive di non poterlo fare per
motivi di licenza.  Cosa comunque che ridurrebbe il numero di file ma
non l'occupazione di memoria/disco.  Se quindi non intende rischiare in
futuro che l'installazione del suo applicativo non funzioni su un Linux
diverso da quello su cui è stato sviluppato, o che aggiornamenti futuri
delle librerie che usa le rendino incompatibili con il suo applicativo,
e se vuole anche evitarsi di dover aggiornare il suo applicativo per
questioni esterne allo stesso, l'unica scelta è quella delle librerie
specifiche.


 sull'impostazione per l'intero sistema di LD_LIBRARY_PATH.
 
Quando trovo un po' di tempo rileggererò le UNIX Admin Horror Stories.
 
 
 

 che sia significativo (e non è neanche questo il posto per chiedere).
 
 
Eventualmente per approfondire nello specifico dove mi consigli di 
spostarmi?
 
Grazie!
Marco

 Marco
 
Sintetizzando se ti e' possibile e' meglio usare il package manager standard 
del sistema in uso per installare tutto il necessario/possibile usando i 
pacchetti standard sispobili.
 
Il programma e le SUE LIBRERIE (non quelle di sistema e altro) puo' essere 
installato con uno script o altro (basta vedere quello che viene installato 
per esempio da ' make install ' (se si usano gli autotools)).
 
 
E volendo non e' nemmeno necessario creare un package per il programma da 
installare, basta farsi una lista di dipendenze PRINCIPALI e installarle 
usando il packet manager (per esempio se installi le qt-devel viene 
installato anche tutto il resto della marea di pacchetti necessaria).
 
 
 
L'altra soluzione e' di compilare le librerie come statiche all'interno del 
programma, in modo che si porta dietro tutto il necessario.

 spostarmi?
 
Già avevo suggerito it.comp.os.linux.development

 Già avevo suggerito it.comp.os.linux.development
 
 
scribb...scribb..
 
Ciao e grazie!
Marco