Soluzione 1:
Mi scuso per aver risposto direttamente a tutto, ma non conosco nessun tutorial, FAQ, ecc.
1. Come faccio a capire quali argomenti passare a ./configure?
Esercitati davvero. Autotools è abbastanza semplice in quanto è coerente. Ma ci sono un sacco di cose là fuori che usano cmake o script di build personalizzati. In generale, non dovresti passare nulla da configurare, dovrebbe capire se il tuo sistema può compilare foo-tool o meno.
Gli strumenti Configure e GNU cercano tutti le dipendenze in /, /usr e /usr/local. Se installi qualcosa da qualche altra parte (il che rende le cose dolorose se la dipendenza è stata installata da MacPorts o Fink), dovrai passare un flag per configurare o modificare l'ambiente della shell per aiutare gli strumenti GNU a trovare queste dipendenze.
2. Come funzionano le librerie condivise sotto OS X/Linux:dove risiedono nel filesystem, come ./configure &&make le trova, cosa succede effettivamente quando sono collegate
Su Linux devono essere installati in un percorso che il linker dinamico può trovare, questo è definito dal LD_LIBRARY_PATH variabile d'ambiente e il contenuto di /etc/ld.conf. Su Mac è quasi sempre lo stesso per la maggior parte dei software open source (a meno che non si tratti di un progetto Xcode). Tranne che la variabile env è DYLD_LIBRARY_PATH invece.
Esiste un percorso predefinito in cui il linker cerca le librerie. È /lib:/usr/lib:/usr/local/lib
Puoi integrare questo utilizzando la variabile CPATH, o CFLAGS o un numero qualsiasi di altre variabili d'ambiente davvero (comodamente complicate). Suggerisco CFLAGS in questo modo:
export CFLAGS="$CFLAGS -L/nuovo/percorso"
Il parametro -L si aggiunge al percorso del collegamento.
Le cose moderne usano lo strumento pkg-config. Le cose moderne che installi installano anche un file .pc che descrive la libreria e dove si trova e come collegarsi ad essa. Questo può rendere la vita più facile. Ma non viene fornito con OS X 10.5, quindi dovrai installarlo anche tu. Inoltre, molti sviluppatori di base non lo supportano.
L'atto del collegamento è semplicemente "risolvere questa funzione in fase di esecuzione", in realtà è una grande tabella di stringhe.
3. Quali sono le effettive differenze tra una libreria condivisa e una libreria collegata staticamente? Perché non posso semplicemente collegare staticamente tutto (la RAM e lo spazio su disco costano poco di questi tempi) e quindi evitare strani conflitti di versione della libreria?
Quando ti colleghi a un file di libreria statica, il codice diventa parte della tua applicazione. Sarebbe come se ci fosse un gigantesco file .c per quella libreria e tu lo compilassi nella tua applicazione.
Le librerie dinamiche hanno lo stesso codice, ma quando l'app viene eseguita, il codice viene caricato nell'app in fase di esecuzione (spiegazione semplificata).
Puoi collegarti staticamente a tutto, tuttavia, purtroppo quasi nessun sistema di compilazione lo rende facile. Dovresti modificare manualmente i file di sistema di compilazione (ad es. Makefile.am o CMakeLists.txt). Tuttavia, probabilmente vale la pena impararlo se installi regolarmente elementi che richiedono versioni diverse delle librerie e trovi difficile installare le dipendenze in parallelo.
Il trucco è cambiare la linea di collegamento da -lfoo a -l/path/to/static/foo.a
Probabilmente puoi trovare e sostituire. Successivamente controlla che lo strumento non si colleghi a .so o dylib usando ldd foo o otool -L foo
Un altro problema è che non tutte le librerie vengono compilate in librerie statiche. Molti lo fanno. Ma poi MacPorts o Debian potrebbero aver deciso di non distribuirlo.
4. Come posso sapere quali librerie ho installato e quali versioni?
Se hai i file pkg-config per quelle librerie è facile:
pkg-config --list-all
Altrimenti spesso non puoi facilmente. La dylib può avere un soname (es. foo.0.1.dylib, il soname è 0.1) che è lo stesso della versione della libreria. Tuttavia questo non è richiesto. Il soname è una caratteristica di computabilità binaria, devi saltare la maggior parte del soname se cambi il formato delle funzioni nella libreria. Quindi puoi ottenere ad es. versione 14.0.5 soname per una libreria 2.0. Anche se questo non è comune.
Mi sono sentito frustrato da questo genere di cose e ho sviluppato una soluzione per questo su Mac, e ne parlerò dopo.
5. Come posso installare più di una versione di una libreria senza danneggiare il mio normale sistema?
La mia soluzione è qui:http://github.com/mxcl/homebrew/
Mi piace installare dal sorgente e volevo uno strumento che lo rendesse facile, ma con una certa gestione dei pacchetti. Quindi con Homebrew costruisco, ad es. wget me stesso dai sorgenti, ma assicurati di installare con un prefisso speciale:
/usr/local/Cellar/wget/1.1.4
Quindi utilizzo lo strumento homebrew per collegare simbolicamente tutto ciò in /usr/local, quindi ho ancora /usr/local/bin/wget e /usr/local/lib/libwget.dylib
In seguito, se avrò bisogno di una versione diversa di wget, posso installarla in parallelo e modificare semplicemente la versione collegata all'albero /usr/local.
6. Se sto installando materiale dal sorgente su un sistema che è altrimenti gestito tramite pacchetti, qual è il modo più pulito per farlo?
Credo che il modo Homebrew sia il più pulito, quindi usalo o fai l'equivalente. Installa in /usr/local/pkgs/name/version e link simbolico o hard link al resto.
Usa /usr/local. Ogni strumento di compilazione esistente cerca lì dipendenze e intestazioni. La tua vita sarà molto più facile.
7. Supponendo che riesca a compilare qualcosa di complicato dalla fonte, come posso quindi impacchettarlo in modo che altre persone non debbano saltare attraverso gli stessi cerchi? In particolare su OS X....
Se non ha dipendenze puoi tarare la directory di build e darla a qualcun altro che può quindi fare "make install". Tuttavia, puoi farlo in modo affidabile solo per le stesse identiche versioni di OS X. Su Linux probabilmente funzionerà per Linux simili (ad es. Ubuntu) con la stessa versione del kernel e la stessa versione minore di libc.
Il motivo per cui non è facile distribuire binari su Unix è a causa della compatibilità binaria. Le persone GNU e tutti gli altri cambiano spesso le loro interfacce binarie.
Fondamentalmente non distribuire binari. Le cose probabilmente si romperanno in modi molto strani.
Su Mac, l'opzione migliore è creare un pacchetto macports. Tutti usano macport. Su Linux ci sono così tanti diversi sistemi di compilazione e combinazioni, non credo ci sia consiglio migliore che scrivere un post sul blog su come sei riuscito a creare x tool nella tua strana configurazione.
Se crei una descrizione del pacchetto (per macports o homebrew), chiunque può installare quel pacchetto e risolve anche i problemi di dipendenza. Tuttavia, questo spesso non è facile, e non è nemmeno facile includere la ricetta di macports nell'albero principale di macports. Inoltre macports non supporta tipi di installazione esotici, offre una scelta per tutti i pacchetti.
Uno dei miei obiettivi futuri con Homebrew è rendere possibile fare clic su un collegamento su un sito Web (ad es. homebrew://blah e scaricherà lo script Ruby, installerà i deps per quel pacchetto e quindi creerà l'app. Ma sì, non ancora fatto, ma non troppo complicato considerando il design che ho scelto.
8. Quali sono gli strumenti della riga di comando che devo padroneggiare per diventare bravo in queste cose? Roba come otool, pkg-config ecc.
otool è davvero utile solo dopo. Ti dice a cosa si collega il binario costruito. Quando stai cercando di capire le dipendenze di uno strumento che devi costruire, è inutile. Lo stesso vale per pkg-config poiché avrai già installato la dipendenza prima di poterla utilizzare.
La mia catena di strumenti è, leggi i file README e INSTALL ed esegui un configure --help. Guarda l'output della build per verificare che sia corretto. Analizza eventuali errori di compilazione. Forse in futuro, chiedi su serverfault :)
Soluzione 2:
Questo è un argomento enorme, quindi iniziamo con le librerie condivise su Linux (ELF su Linux e Mach-O su OS X), Ulrich Drepper ha una buona introduzione alla scrittura di DSO (oggetti dinamici condivisi) che copre un po' di storia delle librerie condivise su Linux disponibili qui compreso il motivo per cui sono importanti
Ulrich descrive anche perché il collegamento statico è considerato dannoso, uno dei punti chiave qui sono gli aggiornamenti di sicurezza. I buffer overflow in una libreria comune (ad es. zlib) che è ampiamente collegata staticamente possono causare un enorme sovraccarico per le distribuzioni - questo si è verificato con zlib 1.1.3 (Red Hat advisory)
ELF
La pagina man del linker ld.so
man ld.so
spiega i percorsi e i file di base coinvolti nel collegamento dinamico in fase di esecuzione. Sui moderni sistemi Linux vedrai percorsi aggiuntivi aggiunti tramite /etc/ld.so.conf.d/ aggiunti di solito tramite un glob include in /etc/ld.so.conf.
Se vuoi vedere cosa è disponibile dinamicamente tramite la tua configurazione ld.so puoi eseguire
ldconfig -v -N -X
Leggere l'howto del DSO dovrebbe darti un buon livello di conoscenza di base per poi continuare a capire come questi principi si applicano a Mach-O su OS X.
Mach-O
Su OS X il formato binario è Mach-O. La documentazione del sistema locale per il linker è
man dyld
La documentazione del formato Mach è disponibile presso Apple
Strumenti di compilazione UNIX
Il comune configure , make , make install Il processo è generalmente fornito da GNU autotools che ha un libro online che copre parte della storia della divisione di configurazione/build e della toolchain GNU. Autoconf utilizza i test per determinare la disponibilità delle funzionalità sul sistema di build di destinazione, utilizza il linguaggio macro M4 per guidarlo. Automake è fondamentalmente un metodo di creazione di modelli per Makefile, il modello viene generalmente chiamato Makefile.am che emette un Makefile.in che l'output di autoconf (lo script di configurazione) converte in un Makefile.
Il programma GNU hello funge da buon esempio per comprendere la toolchain GNU e il manuale include la documentazione di autotools.
Soluzione 3:
Simone! So come ti senti; Ho faticato anche con questa parte dell'apprendimento di Linux. Sulla base delle mie esperienze, ho scritto un tutorial su alcuni degli elementi che affronti (principalmente come riferimento per me stesso!):http://easyaspy.blogspot.com/2008/12/buildinginstalling-application-from.html. Penso che apprezzerai la mia nota su quanto siano semplici le applicazioni Python da costruire/installare. :)
Spero che questo aiuti! E buona compilazione.
Tim Jones
Creazione/Installazione di un'applicazione dal sorgente in Ubuntu Linux
Mentre i repository di Ubuntu sono pieni zeppi di fantastiche applicazioni, prima o poi ti imbatterai in quello strumento "indispensabile" che non è nei repository (o non ha un pacchetto Debian) o hai bisogno di un versione più recente rispetto ai repository. cosa fai? Bene, devi creare l'applicazione dal sorgente! Non preoccuparti, in realtà non è così complicato come sembra. Ecco alcuni suggerimenti, basati sulla mia esperienza nel passare dall'essere un dilettante di rango! (Anche se sto usando Ubuntu per questo esempio, i concetti generali dovrebbero essere applicabili alla maggior parte delle distribuzioni Unix/Linux, come Fedora, e persino alla piattaforma Cygwin su Windows.)
Il processo di base per costruire (compilare) la maggior parte delle applicazioni dal sorgente segue questa sequenza:configure --> compile --> install. I tipici comandi Unix/Linux per fare queste cose sono:config --> make --> make install . In alcuni casi, troverai persino pagine Web che mostrano che tutti questi possono essere combinati in un unico comando:
$ config && make && make install
Naturalmente, questo comando presuppone che non ci siano problemi in nessuno di questi passaggi. È qui che entra in gioco il divertimento!
Per iniziare
Se non hai mai compilato un'applicazione dai sorgenti sul tuo sistema, probabilmente avrai bisogno di configurarla con alcuni strumenti di sviluppo generici, come gcc suite del compilatore, alcuni file di intestazione comuni (pensa a questo come codice che è già stato scritto da qualcun altro che viene utilizzato dal programma che stai installando) e lo strumento make. Fortunatamente, in Ubuntu esiste un metapacchetto chiamato build-essential che installerà di questo. Per installarlo (o semplicemente assicurati di averlo già!), esegui questo comando nel terminale:
$ sudo apt-get install build-essential
Ora che hai la configurazione di base, scarica i file sorgente dell'applicazione e salvali in una directory per la quale disponi dei permessi di lettura/scrittura, come la tua directory "home". Tipicamente, questi saranno in un file di archivio con estensione file di .tar.gz o .tar.bz2 . Il .tar significa semplicemente che si tratta di un "archivio su nastro", ovvero un raggruppamento di file che conserva la relativa struttura di directory. Il .gz sta per gzip (GNU zip), che è un popolare formato di compressione Unix/Linux. Allo stesso modo, il .bz2 sta per bzip2, che è un formato di compressione più recente che fornisce una compressione maggiore (dimensioni del file compresso più piccole) rispetto a gzip.
Dopo aver scaricato il file sorgente, apri una finestra di terminale (Terminale di sistema dal menu Ubuntu) e passa alla directory in cui hai salvato il file. (Userò ~/download in questo esempio. Qui, '~' è un collegamento alla tua directory "home".) Usa il comando tar per estrarre i file dal file di archivio scaricato:
Se il tuo file è un archivio gzip (ad esempio, termina con .tar.gz ), usa il comando:
$ tar -zxvf filename.tar.gz
Se il tuo file è un archivio bzip2 (ad esempio, termina con .tar.bz2 ), usa il comando:
$ tar -jxvf filename.tar.gz
Suggerimento:se non vuoi dover ricordare tutte le opzioni della riga di comando per l'estrazione degli archivi, ti consiglio di procurarti una (o entrambe) di queste utilità:dtrx (la mia preferita!) o deco (la più popolare). Con una di queste utilità, devi solo inserire il nome dell'utilità (dtrx o deco) e il nome del file, fa tutto il resto. Entrambi "sanno" come gestire la maggior parte dei formati di archivio che potresti incontrare e hanno un'ottima gestione degli errori.
Quando crei dal sorgente, ci sono due tipi comuni di errori che potresti riscontrare:
- Gli errori di configurazione si verificano quando esegui lo script di configurazione (di solito denominato config o configure) per creare un makefile specifico per la tua configurazione.
- Gli errori del compilatore si verificano quando esegui il comando make (dopo che il makefile è stato generato) e il compilatore non è in grado di trovare il codice di cui ha bisogno.
Esamineremo ognuno di questi problemi e discuteremo come risolverli.
Configurazione ed errori di configurazione
Dopo aver estratto il file di archivio del codice sorgente, nel terminale, dovresti passare alla directory che contiene i file estratti. Tipicamente, questo nome di directory sarà uguale al nome del file (senza .tar.gz o .tar.bz2 estensione). Tuttavia, a volte il nome della directory è solo il nome dell'applicazione, senza alcuna informazione sulla versione.
Nella directory dei sorgenti cerca un README file e/o un INSTALL file (o qualcosa con nomi simili). Questi file in genere contengono informazioni utili su come creare/compilare l'applicazione e installarla, incluse informazioni sulle dipendenze. "Dipendenze" è solo un nome di fantasia per altri componenti o librerie che devono essere compilati correttamente.
Dopo aver letto il README e/o INSTALL file (e, si spera, consultato tutta la documentazione online pertinente per l'applicazione), cercare un file eseguibile (con l'autorizzazione "x" impostata sul file) denominato config o configure . A volte il file potrebbe avere un'estensione, come .sh (ad esempio, config.sh ). Di solito si tratta di uno script di shell che esegue altre utilità per confermare che si dispone di un ambiente "sano" per la compilazione. In altre parole, verificherà che tu abbia installato tutto ciò di cui hai bisogno.
Suggerimento:se questa è un'applicazione basata su Python, invece di un file di configurazione, dovresti trovare un file chiamato
setup.pyLe applicazioni .Python sono in genere molto semplici da installare. Per installare questa applicazione, come root (ad esempio, metti sudo davanti al seguente comando sotto Ubuntu), esegui questo comando:$ python setup.py installDovrebbe essere tutto quello che devi fare. Puoi saltare il resto di questo tutorial e procedere direttamente all'utilizzo e al godimento della tua applicazione.
Eseguire lo script di configurazione nel terminale. In genere, puoi (e dovresti!) eseguire il tuo script di configurazione con il tuo normale account utente.
$ ./config
Lo script visualizzerà alcuni messaggi per darti un'idea di cosa sta facendo. Spesso lo script fornisce un'indicazione dell'esito positivo o negativo e, in caso negativo, alcune informazioni sulla causa dell'errore. Se non ricevi alcun messaggio di errore, di solito puoi presumere che tutto sia andato bene.
Se non trovi nessuno script che assomigli a uno script di configurazione, in genere significa che l'applicazione è molto semplice ed è indipendente dalla piattaforma. Ciò significa che puoi semplicemente saltare alla fase di compilazione/compilazione di seguito, perché il Makefile fornito dovrebbe funzionare su qualsiasi sistema.
Un esempio
In questo tutorial, utilizzerò il lettore RSS basato su testo chiamato Newsbeuter come esempio per i tipi di errori che potresti riscontrare durante la creazione della tua applicazione. Per Newsbeuter, il nome dello script di configurazione è config.sh . Sul mio sistema, quando eseguo config.sh , si verificano i seguenti errori:
[email protected]:~/download/newsbeuter-1.3$ ./config.sh
Checking for package sqlite3... not found
You need package sqlite3 in order to compile this program.
Please make sure it is installed.
Facendo alcune ricerche, ho scoperto che, in effetti, il file sqlite3 l'applicazione è stata installata. Tuttavia, dal momento che sto cercando di compilare dal sorgente, questo è un suggerimento che ciò che config.sh sta effettivamente cercando sono le librerie di sviluppo (intestazioni) per sqlite3 . In Ubuntu, la maggior parte dei pacchetti ha un pacchetto corrispondente di sviluppo associato che termina con -dev . (Altre piattaforme, come Fedora, usano spesso un suffisso di pacchetto di -devel per i pacchetti di sviluppo.)
Per trovare il pacchetto appropriato per il sqlite3 pacchetto di sviluppo, possiamo usare il apt-cache utility in Ubuntu (e, analogamente, il file yum utility in Fedora):
[email protected]:~/download/newsbeuter-1.3$ sudo apt-cache search sqlite
Questo comando restituisce un elenco abbastanza lungo di risultati, quindi dobbiamo fare un po' di lavoro investigativo per determinare qual è il pacchetto appropriato. In questo caso, il pacchetto appropriato risulta essere libsqlite3-dev . Nota che a volte il pacchetto che stiamo cercando avrà il lib prefisso, invece dello stesso nome del pacchetto più -dev . Questo perché a volte cerchiamo solo una libreria condivisa che possa essere utilizzata da molte applicazioni diverse. Per installare libsqlite3-dev , esegui il tipico comando apt-get install nel terminale:
[email protected]:~/download/newsbeuter-1.3$ sudo apt-get install libsqlite3-dev
Ora dobbiamo eseguire config.sh di nuovo per assicurarci di aver risolto questo problema di dipendenza e di non avere più problemi di dipendenza. (Anche se non lo mostrerò qui, nel caso di Newsbeuter, ho dovuto installare anche il libcurl4-openssl-dev pacchetto.) Inoltre, se installi un pacchetto di sviluppo (come libsqlite3-dev ) e il pacchetto dell'applicazione associato (ad esempio, sqlite3 ) non è già installato, la maggior parte dei sistemi installerà automaticamente contemporaneamente il pacchetto dell'applicazione associato.
Quando la configurazione viene eseguita correttamente, il risultato sarà che creerà uno o più file make. Questi file sono in genere denominati Makefile (ricorda che maiuscole e minuscole sono importanti in Unix/Linux!). Se il pacchetto di compilazione include sottodirectory, come src , ecc., ciascuna di queste sottodirectory conterrà un Makefile , pure.
Errori di costruzione e compilazione
Ora siamo pronti per compilare effettivamente l'applicazione. Questo è spesso chiamato edificio e il nome è preso in prestito dal processo reale di costruzione di qualcosa. I vari "pezzi" dell'applicazione, che in genere sono più file di codice sorgente, vengono combinati insieme per formare l'applicazione complessiva. L'utilità make gestisce il processo di compilazione e chiama altre applicazioni, come il compilatore e il linker, per eseguire effettivamente il lavoro. Nella maggior parte dei casi, esegui semplicemente make (con il tuo normale account utente) dalla directory in cui hai eseguito la configurazione. (In alcuni casi, come la compilazione di applicazioni scritte con la libreria Qt, dovrai invece eseguire un'altra applicazione "wrapper" come qmake. Ancora una volta, controlla sempre README e/o INSTALL documenti per i dettagli.)
Come con lo script di configurazione sopra, quando esegui make (o l'utilità simile) nel terminale, verranno visualizzati alcuni messaggi su ciò che è in esecuzione ed eventuali avvisi ed errori. In genere puoi ignorare gli avvisi, poiché sono principalmente per gli sviluppatori dell'applicazione e dicono loro che ci sono alcune pratiche standard che vengono violate. Di solito, questi avvisi non influiscono sulla funzione dell'applicazione. D'altra parte, gli errori del compilatore devono essere affrontati. Con Newsbeuter, quando ho eseguito make, le cose sono andate bene per un po', ma poi ho ricevuto un errore:
[email protected]:~/download/newsbeuter-1.3$ make
...
c++ -ggdb -I/sw/include -I./include -I./stfl -I./filter -I. -I./xmlrss -Wall -Wextra -DLOCALEDIR=\"/usr/local/share/locale\" -o src/configparser.o -c src/configparser.cpp
c++ -ggdb -I/sw/include -I./include -I./stfl -I./filter -I. -I./xmlrss -Wall -Wextra -DLOCALEDIR=\"/usr/local/share/locale\" -o src/colormanager.o -c src/colormanager.cpp
In file included from ./include/pb_view.h:5,
from src/colormanager.cpp:4:
./include/stflpp.h:5:18: error: stfl.h: No such file or directory
In file included from ./include/pb_view.h:5,
from src/colormanager.cpp:4:
./include/stflpp.h:33: error: ISO C++ forbids declaration of \u2018stfl_form\u2019 with no type
./include/stflpp.h:33: error: expected \u2018;\u2019 before \u2018*\u2019 token
./include/stflpp.h:34: error: ISO C++ forbids declaration of \u2018stfl_ipool\u2019 with no type
./include/stflpp.h:34: error: expected \u2018;\u2019 before \u2018*\u2019 token
make: *** [src/colormanager.o] Error 1
Il processo make si interromperà non appena si verificherà il primo errore. La gestione degli errori del compilatore a volte può essere un affare complicato. Devi guardare gli errori per alcuni indizi sul problema. In genere, il problema è che alcuni file di intestazione, che di solito hanno estensione .h o .hpp , mancano. Nel caso dell'errore di cui sopra, è (o dovrebbe essere!) chiaro che il problema è che stfl.h file di intestazione non può essere trovato. Come mostra questo esempio, vuoi esaminare le prime righe del messaggio di errore e procedere verso il basso per trovare la causa sottostante del problema.
Dopo aver esaminato la documentazione di Newsbeuter (cosa che avrei dovuto fare prima di iniziare, ma questa parte del tutorial non sarebbe molto significativa!), ho scoperto che richiede una libreria di terze parti chiamata STFL. Quindi cosa facciamo in questo caso? Bene, essenzialmente ripetiamo esattamente lo stesso processo per quella libreria richiesta:ottieni la libreria ed esegui il processo di configurazione-build-install per essa e, quindi, riprendi a costruire l'applicazione desiderata. Ad esempio, nel caso di STFL, ho dovuto installare libncursesw5-dev pacchetto per farlo costruire correttamente. (Di solito, non è necessario ripetere il passaggio di configurazione sulla nostra applicazione originale dopo aver installato un'altra applicazione richiesta, ma non fa mai male.)
Dopo aver installato correttamente il toolkit STFL, il processo make per Newsbeuter è stato eseguito correttamente. Il processo make tipicamente riprende da dove si era interrotto (nel punto in cui si è verificato l'errore). Pertanto, tutti i file che sono già stati compilati correttamente non verranno ricompilati. Se vuoi ricompilare tutto, puoi eseguire make clean all per rimuovere tutti gli oggetti compilati e quindi eseguire nuovamente make.
Installazione
Al termine del processo di compilazione, sei pronto per installare l'applicazione. Nella maggior parte dei casi, per installare l'applicazione nelle aree comuni del file system (ad esempio, /usr/bin o /usr/share/bin , ecc.), sarà necessario eseguire l'installazione come root. L'installazione è davvero il passaggio più semplice dell'intero processo. Per installare, nel terminale eseguire:
$ make install
Controllare l'output di questo processo per eventuali errori. Se tutto è andato a buon fine, dovresti essere in grado di eseguire il nome del comando nel terminale e verrà avviato. (Aggiungi &alla fine della riga di comando, se si tratta di un'applicazione GUI, altrimenti non sarai in grado di utilizzare la sessione del terminale fino al termine dell'esecuzione dell'applicazione.)
Quando crei un'applicazione dal sorgente, in genere non aggiungerà un'icona o un collegamento ai menu della GUI in Ubuntu. Dovrai aggiungerlo manualmente.
E questo è fondamentalmente il processo, sebbene potenzialmente iterativo, per creare e installare un'applicazione dal sorgente in Ubuntu. Dopo averlo fatto solo poche volte, diventerà una seconda natura per te!
Soluzione 4:
Bene, ./configure --help ti darà molte informazioni, per i file di configurazione generati da GNU autotools. La maggior parte si riduce a --with/--without per abilitare le funzionalità (queste possono richiedere un parametro aggiuntivo, come "shared" per dire dove trovare la libreria).
Altri importanti sono --prefix (il cui valore predefinito è /usr/local/ la maggior parte delle volte) per dire dove installare (se stai creando pacchetti di solito lo vuoi come --prefix=/usr o forse --prefix =/opt/Il tuo pacchetto).
Su Linux, /lib, /usr/lib e /usr/local/lib vengono generalmente cercati nel mio gcc e inclusi nella configurazione predefinita di ldconfig. A meno che tu non abbia una buona ragione, è qui che vuoi le tue librerie. Tuttavia, /etc/ld.so.conf può elencare voci aggiuntive.
configure e falli trovare semplicemente tentando di eseguire "gcc -l" e verificando se si verifica un errore. Puoi aggiungere "-L" al parametro CFLAGS per aggiungere ulteriori percorsi di ricerca.
Puoi avere più versioni installate e il software collegato a una versione precedente rimarrà collegato a essa (esegui ldd per scoprire l'associazione su Linux), ma le nuove compilazioni generalmente prendono di mira l'ultima versione di una libreria dinamica sul tuo sistema.
La maggior parte del software presuppone librerie dinamiche, soprattutto se utilizza libtool, quindi potresti scoprire che app non banali non vengono compilate correttamente in modo statico.
ls -l è la soluzione migliore per trovare le librerie installate.
Ed è qui che sono senza informazioni; come giocare bene con i pacchetti:non lo so. Quando possibile, cerco di avvolgere le cose in un pacchetto per evitare il problema.
Soluzione 5:
Per rispondere a un po' della tua domanda ho trovato un buon modo l'altro giorno per vedere quali librerie hai installato e le versioni (questo è su Linux Debian quindi dovrebbe funzionare anche con altre versioni).
dpkg --list
Dovresti ottenere un elenco molto lungo con un output come questo
ii libssl0.9.8 0.9.8c-4etch5 SSL shared libraries
ii libssp0 4.1.1-21 GCC stack smashing protection library
ii libstdc++5 3.3.6-15 The GNU Standard C++ Library v3
ii libstdc++5-3.3 3.3.6-15 The GNU Standard C++ Library v3 (development
ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3