Skip to content

Imparare a compilare dai sorgenti (su Unix/Linux/OSX)

Il nostro gruppo di redattori ha passato lunghe ore a cercare la risposta alla tua ricerca, ti forniamo le risposte in modo che il nostro obiettivo sia quello di essere di grande supporto per te.

Soluzione:

Soluzione 1:

Mi scuso per aver risposto direttamente a tutto, ma non conosco alcun tutorial utile, FAQ, ecc. Fondamentalmente ciò che segue è frutto di 8 anni di creazione di applicazioni desktop (che aiuto a distribuire), frustrazione e ricerca su Google:

1. Come faccio a capire quali argomenti passare a ./configure?

Pratica in realtà. Autotools è abbastanza facile in quanto coerente. Ma c'è un sacco di roba là fuori che usa cmake o script di compilazione personalizzati. In generale, non si dovrebbe passare nulla a configure, dovrebbe capire se il sistema può costruire foo-tool o meno.

Configure e gli strumenti GNU cercano tutte le dipendenze in /, /usr e /usr/local. Se si installa qualcosa da qualche altra parte (il che rende le cose difficili se la dipendenza è stata installata da MacPorts o Fink), si dovrà passare un flag a Configure o modificare l'ambiente della shell per aiutare gli strumenti GNU a trovare queste dipendenze.

2. Come funzionano le librerie condivise in OS X / Linux: dove si trovano nel filesystem, come ./configure && make le trovano, cosa succede quando vengono linkate.

Su Linux devono essere installate in un percorso che il linker dinamico può trovare, definito dal parametro LD_LIBRARY_PATH e dal contenuto di /etc/ld.conf. Su Mac è quasi sempre la stessa cosa per la maggior parte del software open source (a meno che non si tratti di un progetto Xcode). Solo che la variabile d'ambiente è DYLD_LIBRARY_PATH invece di.

Esiste un percorso predefinito in cui il linker cerca le librerie. È /lib:/usr/lib:/usr/local/lib

Si può integrare questo percorso usando la variabile CPATH, o CFLAGS o qualsiasi altra variabile d'ambiente (convenientemente complicata). 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. Il materiale moderno che si installa installa anche un file .pc che descrive la libreria, dove si trova e come collegarla. Questo può rendere la vita più facile. Ma non viene fornito con OS X 10.5, quindi dovrete installare anche quello. Inoltre, molti programmi di base non lo supportano.

L'atto del collegamento è solo "risolvere questa funzione in fase di esecuzione", in realtà è una grande tabella di stringhe.

3. Quali sono le reali differenze tra una libreria condivisa e una collegata staticamente? Perché non è possibile collegare staticamente tutto (la RAM e lo spazio su disco sono economici di questi tempi) e quindi evitare strani conflitti di versione delle librerie?

Quando si collega un file di libreria statica, il codice diventa parte della propria applicazione. Sarebbe come se ci fosse un enorme file .c per quella libreria e lo si compilasse nella propria applicazione.

Le librerie dinamiche hanno lo stesso codice, ma quando l'applicazione viene eseguita, il codice viene caricato nell'applicazione in fase di esecuzione (spiegazione semplificata).

È possibile collegare staticamente tutto, ma purtroppo quasi nessun sistema di compilazione lo rende facile. Bisogna modificare manualmente i file del sistema di compilazione (per esempio Makefile.am o CMakeLists.txt). Tuttavia, probabilmente vale la pena di imparare questo metodo se si installano regolarmente cose che richiedono versioni diverse di librerie e si trova difficile installare le dipendenze in parallelo.

Il trucco consiste nel cambiare la linea di collegamento da -lfoo a -l/path/to/static/foo.a

Probabilmente si può trovare e sostituire. Successivamente verificare che lo strumento non si colleghi al .so o alla dylib usando ldd foo o otool -L foo

Un altro problema è che non tutte le librerie vengono compilate come librerie statiche. Molte lo fanno. Ma MacPorts o Debian potrebbero aver deciso di non distribuirle.

4. Come posso sapere quali librerie ho installato e quali versioni?

Se si hanno i file pkg-config per quelle librerie è facile:

pkg-config --list-all

Altrimenti spesso non è facile. La dylib può avere un nome figlio (ad esempio, foo.0.1.dylib, il nome figlio è 0.1) che è lo stesso della versione della libreria. Tuttavia questo non è necessario. Il nome soname è una caratteristica di computabilità binaria; se si cambia il formato delle funzioni della libreria, è necessario modificare la parte principale del nome soname. Quindi si può ottenere, ad esempio, il nome del figlio della versione 14.0.5 per una libreria 2.0. Anche se questo non è comune.

Sono stato frustrato da questo genere di cose e ho sviluppato una soluzione per questo problema su Mac, di cui parlerò prossimamente.

5. Come posso installare più di una versione di una libreria senza rompere il mio sistema normale?

La mia soluzione è qui: http://github.com/mxcl/homebrew/

Mi piace installare dai sorgenti e volevo uno strumento che lo rendesse facile, ma con una certa gestione dei pacchetti. Quindi con Homebrew costruisco, per esempio, wget da solo dai sorgenti, ma mi assicuro di installare con un prefisso speciale:

/usr/local/Cellar/wget/1.1.4

Poi uso lo strumento homebrew per collegare in symlink tutto questo in /usr/local, in modo da avere ancora /usr/local/bin/wget e /usr/local/lib/libwget.dylib

In seguito, se avrò bisogno di una versione diversa di wget, potrò installarla in parallelo e cambiare semplicemente la versione collegata all'albero /usr/local.

6. Se sto installando qualcosa dai sorgenti su un sistema che è altrimenti gestito tramite pacchetti, qual è il modo più pulito di farlo?

Credo che il metodo Homebrew sia il più pulito, quindi usatelo o fate l'equivalente. Installare in /usr/local/pkgs/nome/versione e collegare in symlink o hard link il resto.

Usare /usr/local. Ogni strumento di compilazione esistente cerca lì le dipendenze e le intestazioni. La vostra vita sarà molto più facile.

7. Supponendo che io riesca a compilare qualcosa di complicato dai sorgenti, come posso poi confezionarlo in modo che altre persone non debbano fare gli stessi salti mortali? In particolare su OS X....

Se non ci sono dipendenze, si può creare una cartella di compilazione e darla a qualcun altro che può fare "make install". Tuttavia è possibile farlo in modo affidabile solo per le stesse versioni di OS X. Su Linux probabilmente funzionerà per Linux simili (ad esempio Ubuntu) con la stessa versione del Kernel e la stessa versione minore di libc.

La ragione per cui non è facile distribuire binari su Unix è la compatibilità binaria. Il popolo GNU e tutti gli altri cambiano spesso le loro interfacce binarie.

In pratica non distribuite binari. Probabilmente le cose si romperanno in modi molto strani.

Su Mac, l'opzione migliore è creare un pacchetto macports. Tutti usano macports. Su Linux ci sono così tanti sistemi di compilazione e combinazioni diverse, che non credo ci sia un consiglio migliore che scrivere un post sul blog su come si è riusciti a compilare lo strumento x con la configurazione y.

Se si fa una descrizione del pacchetto (per macport o homebrew) allora chiunque può installare quel pacchetto, risolvendo anche i problemi di dipendenza. Tuttavia questo spesso non è facile, e non è nemmeno facile far includere la propria ricetta macports nell'albero principale di macports. Inoltre macports non supporta tipi di installazione esotici, ma offre una sola scelta per tutti i pacchetti.

Uno dei miei obiettivi futuri con Homebrew è quello di rendere possibile cliccare su un link in un sito web (es. homebrew://blah) e scaricare lo script Ruby, installare i deps per quel pacchetto e quindi compilare l'applicazione. Ma sì, non è ancora finito, ma non è troppo complicato considerando il design che ho scelto.

8. Quali sono gli strumenti a riga di comando che devo padroneggiare per diventare bravo in queste cose? Cose come otool, pkg-config ecc.

otool è utile solo dopo. Vi dice a cosa si collega il binario costruito. Quando si stanno calcolando le dipendenze di uno strumento che si deve costruire, è inutile. Lo stesso vale per pkg-config, dato che la dipendenza deve essere già installata prima di poterla usare.

La mia catena di strumenti è: leggere i file README e INSTALL e fare un configure --help. Osservare l'output di compilazione per verificare che sia corretto. Analizzare eventuali errori di compilazione. Forse in futuro, chiedere su serverfault 🙂

Soluzione 2:

Questo è un argomento molto vasto, quindi cominciamo con le librerie condivise su Linux (ELF su Linux e Mach-O su OS X), Ulrich Drepper ha una buona introduzione alla scrittura dei DSO (dynamic shared objects) che copre un po' di storia delle librerie condivise su Linux, disponibile qui, incluso il motivo per cui sono importanti

Ulrich descrive anche perché il linking statico è considerato dannoso, uno dei punti chiave è l'aggiornamento della sicurezza. I buffer overflow in una libreria comune (ad esempio zlib) che è ampiamente linkata staticamente possono causare un enorme overhead per le distribuzioni - questo si è verificato con zlib 1.1.3 (Red Hat advisory)

ELF

La pagina di manuale del linker ld.so

man ld.so 

spiega i percorsi e i file di base coinvolti nel linking dinamico a runtime. Nei moderni sistemi Linux si vedranno percorsi aggiuntivi aggiunti tramite /etc/ld.so.conf.d/ aggiunti di solito tramite un glob include in /etc/ld.so.conf.

Se si vuole vedere cosa è disponibile dinamicamente attraverso la configurazione di ld.so, si può eseguire

ldconfig -v -N -X

La lettura dell'howto di DSO dovrebbe fornire un buon livello di conoscenza di base per poter poi capire come questi principi si applicano a Mach-O su OS X.

Mach-O

Su OS X il formato binario è Mach-O. La documentazione di sistema locale per il linker è

man dyld

La documentazione sul formato Mach è disponibile presso Apple

Strumenti di compilazione UNIX

Il comune configure, make, make install è generalmente fornito da GNU autotools, che ha un libro online che copre parte della storia della divisione configure/build e della catena di strumenti GNU. Autoconf usa i test per determinare la disponibilità delle caratteristiche sul sistema di compilazione di destinazione, e usa il linguaggio macro M4 per farlo. Automake è fondamentalmente un metodo di template per i Makefile, il template generalmente si chiama Makefile.am che produce un Makefile.in che l'output di autoconf (lo script configure) converte in un Makefile.

Il programma GNU hello è un buon esempio per comprendere la catena di strumenti GNU e il manuale include la documentazione di autotools.


Soluzione 3:

Simon! So come ti senti; anch'io ho lottato con questa parte dell'apprendimento di Linux. Basandomi sulle mie esperienze, ho scritto un tutorial su alcuni degli argomenti che hai trattato (soprattutto come riferimento per me stesso!): http://easyaspy.blogspot.com/2008/12/buildinginstalling-application-from.html. Penso che apprezzerete la mia nota su quanto siano semplici le applicazioni Python da costruire/installare. 🙂

Spero che questo sia d'aiuto! E buona compilazione.

Tim Jones


Costruire/Installare un'applicazione dai sorgenti in Ubuntu Linux

Sebbene i repository di Ubuntu siano pieni di ottime applicazioni, prima o poi vi capiterà di imbattervi in quello strumento "indispensabile" che non è presente nei repository (o che non ha un pacchetto Debian) o di cui vi serve una versione più recente rispetto a quella presente nei repository. Cosa si fa? Beh, bisogna compilare l'applicazione dai sorgenti! Non preoccupatevi, non è così complicato come sembra. Ecco alcuni consigli, basati sulla mia esperienza di dilettante allo sbaraglio! (Anche se per questo esempio utilizzo Ubuntu, 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 di creazione (compilazione) della maggior parte delle applicazioni dai sorgenti segue questa sequenza: configura --> compila --> installa. I comandi tipici di Unix/Linux per eseguire queste operazioni sono: config --> make --> make install. In alcuni casi, si trovano anche pagine web che mostrano che tutti questi comandi 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 viene il bello!

Iniziare

Se non avete mai compilato un'applicazione dai sorgenti sul vostro sistema, probabilmente dovrete configurarla con alcuni strumenti di sviluppo generali, come ad esempio il programma gcc alcuni file di intestazione comuni (si pensi al codice già scritto da qualcun altro e utilizzato dal programma che si sta installando) e lo strumento make. Fortunatamente, in Ubuntu, esiste un metapacchetto chiamato build-essential che installa tutto questo. Per installarlo (o semplicemente per assicurarsi di averlo già!), eseguite questo comando nel terminale:

$ sudo apt-get install build-essential

Ora che avete la configurazione di base, scaricate i file sorgente dell'applicazione e salvateli in una directory per la quale avete i permessi di lettura/scrittura, come la vostra directory "home". In genere, questi file sono contenuti in un archivio con estensione .tar.gz o .tar.bz2. Il file .tar significa semplicemente che si tratta di un "archivio a nastro", ovvero un raggruppamento di file che conserva la struttura relativa delle directory. Il simbolo .gz sta per gzip (GNU zip), un popolare formato di compressione Unix/Linux. Allo stesso modo, il simbolo .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, aprite una finestra di terminale (System Terminal dal menu di Ubuntu) e passate alla directory in cui avete salvato il file. (Io userò ~/download in questo esempio. Qui, '~' è una scorciatoia per la vostra directory "home"). Usate il comando tar per estrarre i file dall'archivio scaricato:

Se il file è un archivio gzip (ad esempio, termina con .tar.gz), utilizzare il comando:

            $ tar -zxvf filename.tar.gz

Se il file è un archivio bzip2 (ad es., termina con .tar.bz2), utilizzare il comando:

            $ tar -jxvf filename.tar.gz

Suggerimento: se non si desidera dover ricordare
ricordare tutte le opzioni della riga di comando
per l'estrazione degli archivi, consiglio di
raccomandare di procurarsi una (o entrambe) di
queste utility: dtrx (la mia preferita!)
o deco (più popolare). Con una di queste
queste utility, basta inserire il
nome dell'utilità (dtrx o deco) e il nome del file.
il nome del file e il programma fa tutto il resto.
resto. Entrambe "sanno" come
gestire la maggior parte dei formati di archivio che
che si possono incontrare e hanno un'ottima gestione degli errori.
hanno un'ottima gestione degli errori.

Quando si costruisce dai sorgenti, ci sono due tipi comuni di errori che è probabile incontrare:

  1. Gli errori di configurazione si verificano quando si esegue lo script di configurazione (solitamente chiamato config o configure) per creare un makefile specifico per la propria configurazione.
  2. Gli errori del compilatore si verificano quando si esegue il comando make (dopo che il makefile è stato generato) e il compilatore non riesce a trovare il codice di cui ha bisogno.

Esamineremo ciascuno di questi errori e discuteremo come risolverli.

Errori di configurazione e configurazione

Dopo aver estratto il file di archivio del codice sorgente, nel terminale si deve passare alla directory che contiene i file estratti. In genere, il nome di questa directory sarà lo stesso del nome del file (senza il simbolo .tar.gz o .tar.bz2 ). Tuttavia, a volte il nome della directory è solo il nome dell'applicazione, senza alcuna informazione sulla versione.

Nella directory di origine cercate un file README e/o un file INSTALL (o qualcosa con nomi simili). Questi file contengono in genere informazioni utili su come costruire/compilare l'applicazione e installarla, comprese le informazioni sulle dipendenze. Le "dipendenze" sono solo un nome di fantasia per altri componenti o librerie necessari per la compilazione.

Dopo aver letto la sezione README e/o INSTALL (e, auspicabilmente, aver consultato la documentazione online relativa all'applicazione), cercare un file eseguibile (con il permesso "x" impostato sul file) chiamato config o configure. A volte il file può avere un'estensione, come ad esempio .sh (ad esempio, config.sh). Di solito si tratta di uno script di shell che esegue altre utilità per confermare che l'ambiente di compilazione è "sano". In altre parole, controlla che sia installato tutto ciò che serve.

Suggerimento: Se si tratta di un'applicazione basata su Python
invece di un file di configurazione,
si dovrebbe trovare un file chiamato setup.py.
Le applicazioni Python sono in genere molto
semplici da installare. Per installare questa
applicazione, come root (per esempio, mettere sudo
davanti al seguente comando
in Ubuntu), eseguite questo comando:

    $ python setup.py install

Questo dovrebbe essere tutto ciò che
fare. Potete saltare il resto di questa
tutorial e procedere direttamente all'utilizzo
e godersi la propria applicazione.

Eseguire lo script di configurazione nel terminale. In genere, si può (e si deve!) eseguire lo script di configurazione con il proprio account utente.

$ ./config

Lo script visualizzerà alcuni messaggi per dare un'idea di ciò che sta facendo. Spesso lo script indica se è riuscito o fallito e, in caso di fallimento, fornisce alcune informazioni sulla causa del fallimento. Se non vengono visualizzati messaggi di errore, di solito si può ritenere che tutto sia andato bene.

Se non si trova nessuno script che assomigli a uno script di configurazione, significa che l'applicazione è molto semplice e indipendente dalla piattaforma. Questo significa che si può semplicemente saltare al passo di compilazione che segue, perché il file fornito è Makefile fornito dovrebbe funzionare su qualsiasi sistema.

Un esempio

In questo tutorial, utilizzerò il lettore RSS testuale Newsbeuter come esempio dei tipi di errori che si possono incontrare durante la creazione dell'applicazione. Per Newsbeuter, il nome dello script di configurazione è config.sh. Sul mio sistema, quando eseguo config.shsi 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 qualche ricerca, ho scoperto che, in effetti, l'opzione sqlite3 è stata installata. Tuttavia, dal momento che sto cercando di compilare dai sorgenti, questo è un suggerimento che cosa config.sh sta effettivamente cercando le librerie di sviluppo (header) di sqlite3. In Ubuntu, la maggior parte dei pacchetti ha un pacchetto di sviluppo associato che termina in -dev. (Altre piattaforme, come Fedora, spesso usano un suffisso di pacchetto di -devel per i pacchetti di sviluppo).

Per trovare il pacchetto appropriato per la piattaforma sqlite3 di sviluppo, si può usare l'opzione apt-cache di Ubuntu (e, analogamente, l'utility yum in Fedora):

[email protected]:~/download/newsbeuter-1.3$ sudo apt-cache search sqlite

Questo comando restituisce un elenco piuttosto ampio di risultati, quindi dobbiamo fare un po' di lavoro investigativo per determinare quale sia il pacchetto appropriato. In questo caso, il pacchetto appropriato risulta essere libsqlite3-dev. Si noti che a volte il pacchetto che stiamo cercando avrà il simbolo lib invece che lo stesso nome del pacchetto con l'aggiunta di -dev. Questo perché a volte si cerca solo una libreria condivisa che può essere usata da molte applicazioni diverse. Per installare libsqlite3-dev, eseguire 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 per assicurarci di aver risolto questo problema di dipendenza e di non averne altri. (Anche se non lo mostrerò qui, nel caso di Newsbeuter, ho dovuto installare anche il file libcurl4-openssl-dev ). Inoltre, se si installa un pacchetto di sviluppo (come libsqlite3-dev) e il pacchetto applicativo associato (ad esempio, sqlite3) non è già installato, la maggior parte dei sistemi installerà automaticamente il pacchetto applicativo associato nello stesso momento.

Quando la configurazione viene eseguita con successo, il risultato sarà la creazione di uno o più file make. Questi file sono tipicamente denominati Makefile (ricordate che le maiuscole dei nomi dei file sono importanti in Unix/Linux!). Se il pacchetto di compilazione include delle sottodirectory, come ad esempio srceccetera, ciascuna di queste sottodirectory conterrà un file Makefile, anche.

Errori di costruzione e compilazione

Ora siamo pronti a compilare l'applicazione. Questa operazione viene spesso chiamata costruzione 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 svolgere effettivamente il lavoro. Nella maggior parte dei casi, è sufficiente eseguire make (con il proprio account utente) dalla directory in cui è stata eseguita la configurazione. (In alcuni casi, come la compilazione di applicazioni scritte con la libreria Qt, è necessario eseguire un'altra applicazione "wrapper" come qmake. Di nuovo, controllate sempre il campo README e/o INSTALL per i dettagli).

Come per lo script di configurazione di cui sopra, quando si esegue make (o un'utilità simile) nel terminale, vengono visualizzati alcuni messaggi su ciò che si sta eseguendo e su eventuali avvertimenti ed errori. In genere si possono ignorare gli avvertimenti, in quanto sono principalmente destinati agli sviluppatori dell'applicazione e indicano loro che sono state violate alcune pratiche standard. Di solito, questi avvisi non influiscono sul funzionamento dell'applicazione. D'altra parte, gli errori del compilatore devono essere gestiti. 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_formu2019 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_ipoolu2019 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 interrompe non appena viene riscontrato il primo errore. Gestire gli errori del compilatore a volte può essere un affare complicato. Bisogna osservare gli errori per trovare qualche indizio sul problema. In genere, il problema è che alcuni file di intestazione, che di solito hanno un'estensione di .h o .hppsono mancanti. Nel caso dell'errore di cui sopra, è (o dovrebbe essere!) chiaro che il problema è che stfl.h non può essere trovato. Come dimostra questo esempio, è bene guardare le prime righe del messaggio di errore e scendere per trovare la causa del problema.

Dopo aver consultato la documentazione di Newsbeuter (cosa che avrei dovuto fare prima di iniziare, ma poi questa parte del tutorial non avrebbe avuto molto senso!), ho scoperto che richiede una libreria di terze parti chiamata STFL. Quindi cosa facciamo in questo caso? Beh, essenzialmente ripetiamo lo stesso identico processo per la libreria richiesta: otteniamo la libreria ed eseguiamo il processo configure-build-install per essa e, quindi, riprendiamo la costruzione dell'applicazione desiderata. Per esempio, nel caso di STFL, ho dovuto installare la libreria libncursesw5-dev affinché l'applicazione venga compilata correttamente. (Di solito non è necessario rifare la fase di configurazione dell'applicazione originale dopo aver installato un'altra applicazione necessaria, ma non fa mai male).

Dopo aver installato con successo il toolkit STFL, il processo make per Newsbeuter è stato eseguito con successo. Il processo make in genere riprende da dove si era interrotto (al punto in cui si è verificato l'errore). Pertanto, tutti i file che erano già stati compilati con successo non saranno ricompilati. Se si vuole ricompilare tutto, si può eseguire make clean all per rimuovere tutti gli oggetti compilati e poi eseguire nuovamente make.

Installazione

Dopo che il processo di compilazione è stato completato con successo, si è pronti a 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/binecc.), è necessario eseguire l'installazione come root. L'installazione è il passo più semplice dell'intero processo. Per installare, eseguire nel terminale:

$ make install

Controllare l'output di questo processo per verificare la presenza di eventuali errori. Se tutto è andato a buon fine, dovreste essere in grado di eseguire il nome del comando nel terminale e il programma si avvierà. (Se si tratta di un'applicazione GUI, aggiungere & alla fine della riga di comando, altrimenti non sarà possibile utilizzare la sessione del terminale finché l'applicazione non avrà terminato l'esecuzione).

Quando si crea un'applicazione dai sorgenti, di solito non viene aggiunta un'icona o un collegamento ai menu dell'interfaccia grafica di Ubuntu. È necessario aggiungerla manualmente.

Questo è il processo, anche se potenzialmente iterativo, per costruire e installare un'applicazione dai sorgenti in Ubuntu. Dopo averlo fatto un paio di volte, diventerà una seconda natura per voi!


Soluzione 4:

Beh, ./configure --help vi darà molte informazioni sui file di configurazione generati da GNU autotools. La maggior parte si riduce a --with/--without per abilitare le funzioni (queste possono richiedere un parametro aggiuntivo, come "shared" per dire dove trovare la libreria).

Altri importanti sono --prefix (che nella maggior parte dei casi è predefinito a /usr/local/) per dire dove installare (se si stanno creando pacchetti, di solito si vuole --prefix=/usr o forse --prefix=/opt/YourPackage).

Su Linux, /lib, /usr/lib e /usr/local/lib sono generalmente cercati da gcc e inclusi nella configurazione predefinita di ldconfig. A meno che non si abbia una buona ragione, è qui che vanno inserite le librerie. Tuttavia, /etc/ld.so.conf può contenere voci aggiuntive.

configure e make li trovano semplicemente provando a eseguire "gcc -l" e vedendo se dà errore. Si può aggiungere "-L" al parametro CFLAGS per aggiungere altri percorsi da cercare.

È possibile avere più versioni installate, e il software collegato a una versione più vecchia rimarrà collegato ad essa (eseguite ldd per scoprire il binding su Linux), ma le nuove compilazioni in genere puntano all'ultima versione di una libreria dinamica presente sul sistema.

La maggior parte del software presuppone librerie dinamiche, specialmente se usa libtool, quindi è possibile che applicazioni non banali non vengano compilate correttamente in modo statico.

ls -l è la scelta migliore per trovare le librerie installate.

Ed è qui che ho finito le informazioni; come giocare bene con i pacchetti: non lo so. Quando è possibile, cerco di impacchettare le cose in un pacchetto per evitare il problema.


Soluzione 5:

Per rispondere a una parte della vostra domanda, l'altro giorno ho trovato un buon metodo per vedere quali librerie avete installato e le relative versioni (questo è su Linux Debian, quindi dovrebbe funzionare anche con altre versioni).

dpkg --list

Si dovrebbe ottenere una lista molto lunga con un output simile a 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

Se hai delle riserve e dei modi per mettere a punto la nostra cronaca, puoi aggiungere una critica e la analizzeremo volentieri.



Utilizzate il nostro motore di ricerca

Ricerca
Generic filters

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.