Newsgroup: it.comp.os.linux.development
Titolo: path per librerie condivise

Saluti.
Ho un problema con le librerie condivise:
quando si esegue un programma che ne fa uso, la libreria come viene cercata?
Ha provato a far girare un mio programma su di un computer non mio
(e di cui non posso avere accesso come root), e non riesco al far
linkare la libreria.
Grazie  Manlio Perillo  

Manlio Perillo ha scritto:

intendi le .so? tramite ldconfig, la lib deve essere in un path 
contemplato, e dopo l'istallazione, va dato ldconfig.
opure puoi usare dlopen
-- 
Se l'appetito vien mangiando,
Figuriamoci a digiuno...
BW2K+2

Manlio Perillo ha scritto:

intendi le .so? tramite ldconfig, la lib deve essere in un path 
contemplato, e dopo l'istallazione, va dato ldconfig.
opure puoi usare dlopen / dlsym
#include <dlfcn.h>


 
...oppure in uno dei percorsi elencati nella variabile d'ambiente 
LD_LIBRARY_PATH.
Max

 LD_LIBRARY_PATH.
gia', avrei dovuto specificarlo, contemplato stava a significare quello, 
anche :) 
spesso credo, incosciamente, che uno che sa programmare su linux sia 
anche un amministratore decente, cosa che non e' ovviamente sempre vera



Ho provato in vari modi (usando libtool) ma non sono riuscito a
far trovare la mia libreria.
Il tutto funziona se la libreria è installata in /usr/lib ma se è
presente in un'altra directory?
Tieni presente che la libreria è stata compilata con libtool ed il
programma eseguibile non fa uso di dlopen ne di altro.
Con Windows le librerie vengono cercate in base alla variabile di ambiente
PATH, ed in Linux?
Ciao e grazie

 ambiente PATH, ed in Linux?
ti ha gia' risposto Max M.
riposto un pezzo di codice per trovare la directory corrente di un 
programma
NOTA: tutto questo e' molto linux specific, non so neppure se possa 
funzionare su BSD
#include <sys/types.h>
#include <unistd.h>
#include <limits.h>
#include <iostream>
#include <string>
#include <strstream>
int main() {
  pid_t mypid;
  char buffer[16]; 
  /* + che sufficiente per un pid, ed evita di dover fare un delete */
  char percorso[PATH_MAX];
  std::string nomefile="/proc/";
  /*ricava il pid del programma */
  mypid = getpid();
 
  /* lo aggiunge alla stringa che conterra' il percorso del link */
  std::ostrstream os(buffer, 16);
  os << mypid << std::ends;
  std::string pid (os.str());
  nomefile += pid + "/exe";
 
  /* risolve il link */
  readlink(nomefile.c_str(), percorso, PATH_MAX);  
  std::string Percorso(percorso);
  Percorso = Percorso.substr(0, Percorso.find_last_of("/"));
 
  /* stampa */
  std::cout << Percorso << std::endl;  
  return 0;
}
ottenuto il path, reimposti la v. d'ambiente LD_LIBRARY_PATH a runtime, 
aggiungendovi il percorso ottenuto tramite getenv / putenv
occhio che in unix le dir si separano con : e non con ; come in win/dos


   std::string Percorso(percorso);
Attenzione! Come documentato dalla manpage, readlink() *non* aggiunge il
NULL in coda. L'array 'percorso', trattandosi di un tipo built-in non
globale, non viene inizializzato, e potrebbe perciň contenere qualsiasi
cosa. Suggerirei:
   int len = readlink(nomefile.c_str(), percorso, PATH_MAX);
   std::string Percorso( percorso, len > 0 ? len : 0 );
Max

 linkare la libreria.
The necessary shared libraries needed by the program are searched for
in the following order
Using  the environment variable LD_LIBRARY_PATH
(LD_AOUT_LIBRARY_PATH for a.out programs).  Except if
the executable is a setuid/setgid binary, in which case it is ignored.
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
  -<! A conclusion is simply the place where someone got tired of thinking. !>-


E' una delle prime cosa che ho fatto ma non funziona.
Rispiego meglio il problema.
1) Sul mio PC ho compilato la libreria usando libtool.
   L'ho quindi installata in /usr/lib.
2) Sul mio PC ho compilato il programma specificando la libreria con
   -lmialib.
   Il programma non fa uso di dlopen ne altro. Ho linkto la libreria
   come se fosse statica
3) Sul mio PC ho eseguito il programma e funziona.
4) Decido di provare il programma su di un altro PC sui cui non ho accesso
   da root.
   Copio il programma e la libreria ma quando vado ad eseguire il programma
   la libreria non viene trovata.
Spero di essere riuscito a spiegare il problema.
Pensandoci un po su forse questo comportamento è normale e serve
ad evitare problemi di sicurezza (tipo la non presenza della
directory corrente in PATH).
Qualcuno potrebbe installare una libreria 'cavallo di troia' e
farla linkare al posto di quella originale.
Comunque alla fine per risolvare il problema ho creato una versione
statica della libreria.
Saluti e grazie   Manlio Perillo

 statica della libreria.
cioe', linki il prog staticamente? oppure la tua lib. ne richiamava 
altre, che tu avevi, ma l'altro no?


 farla linkare al posto di quella originale.
Per farlo dovrebbe alterare LD_LIBRARY_PATH in tutti gli ambienti.
Max

    la libreria non viene trovata.
sull'altro pc devi lanciare 
ldconfig
Paolo Piersanti
-- 
             Signature for rent!
          Questo spazio si affitta!
contact:
daun...@gmx.net


La prima che hai detto.
Ciao  Manlio Perillo


Non credo.
Per fare una prova, sul mio PC ho cancellato la libreria dinamica da /usr/lib
e l'ho ricompilata ed installata in (diciamo) $HOME/lib.
Ho ricompilato il programma (usando come path per la libreria $HOME/lib) e
l'ho avviato: continua a non trovare la libreria.
Ciao e grazie  Manlio Perillo

 l'ho avviato: continua a non trovare la libreria.
Dunque, in teoria dovrebbe accadere questo. Diciamo che il tuo programma
si chiama "xperillo" e la libreria è "libperillo.so", che è installata in
/usr/lib. xperillo che stato linkato con -lperillo.
  ldd xperillo
dovrebbe, tra le altre cose, scrivere
  libperillo.so -> /usr/lib/libperillo.so (0x........)
Ora, muovi libperillo.so in /tmp/lib... ldd dovrebbe dirti
  libperillo.so -> not found
Ora aggiungi "/tmp/lib" a LD_LIBRARY_PATH
   export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/tmp/lib
Ora ldd dovrebbe dirti
   libperillo.so -> /tmp/lib/libperillo.so (0x........)
Max


Ho provato e funziona, grazie.
Io non usavo export.
Comunque mi sembra strano che tale cosa non la faccia libtool.
Ecco i passi che ho fatto:
libtool c++ -c lib.cpp
libtool c++ -o 
liblib.la
 lib.lo -rpath /home/prova/lib
libtool install 
liblib.la
 /home/prova/lib
Sbaglio qualcosa?


 Sbaglio qualcosa?
libtool non puo' modificare /etc/ld.so.conf dove ci sono 
i path delle librerie condivise. 
per l'utente, puoi mettere le modifiche che ti ha detto Max M. in 
~/.bash_profile (sempre con export finale)
se invece sei amministratore, puoi aggiungere il path a /etc/ld.so.conf
