Compilazione statica di un programma (firefox)

[cressida]

Buongiorno
Utilizzo ancora in un computer una vecchia versione di Slackware (12.2)
Nonostante non sia più supportata e molto del software sia relativamente vecchio, quello di cui più si sente la mancanza è un browser aggiornato.
Con Firefox 3.6 ormai certi siti non sono più visualizzabili e navigabili.
Da qui la mia domanda: è possibile compilare una nuova versione di Firefox per questo sistema appoggiandosi ad una distribuzione più recente (Slackware 14.1)?

[ponce]

che sappia io uno script del genere non esiste e non e' per niente semplice scriverlo.

puoi provare a vedere quello che ti gira dei binari di mozilla

https://ftp.mozilla.org/pub/mozilla.org ... /releases/

comunque il punto e' che dovresti lasciar perdere la 12.2 perche', a prescindere da firefox, non essendo piu' aggiornata non e' sicuro usarla, a maggior ragione con programmi/servizi che fanno uso della rete.

[hashbang]

Forse (e dico forse perché la cosa andrebbe provata di persona) potresti prendere il pacchetto di firefox della 14.1, prendere le librerie dipendenti (libc inclusa) ed estrarre tutto in /opt (o directory da te scelta), per poi fare un launcher che wrappi il binario con LD_LIBRARY_PATH, in modo da far pescare ad ld-linux.so solo le librerie custom incluse nel percorso da te indicato.

Tuttavia non è detto che all'atto pratico sia realmente fattibile. Le versioni recenti del kernel sono retrocompatibili a livello di ABI con Linux 2.6.32, quindi rischieresti incompatibilità binarie con versioni obsolete del kernel; senza contare le possibili rogne con i simboli di GLIBC che sono versioned.

Ad ogni modo, è una procedura a mio modo di vedere sporca e completamente inutile. Meglio la soluzione di ponce di prendere i binari mozilla.
Meglio ancora se aggiorni. Non c'è alcun motivo valido per rimanere con una versione di un sistema operativo ormai dichiarata EOL.

[percoco2000]

Sono nella stessa situazione SIG!...., per adesso arrangio con opera 12.10.
Aggiornare si fa' presto a dirlo, un sistema frutto di anni di tuning e personalizzazioni, e' un casino da rimettere su.
E poi c'e' sempre qualche software "vecchio" , non mantenuto/aggiornato, o che dipende da libs vecchie.....
Giusto per citare il mio caso, uso kaffeine con compilato il supporto a kaffeine-sc. Rifatelo su una slack 14.1 .....

OffTopic. Credo questo sia uno dei "guai" di linux..... Un qualunque XP dello stesso periodo non ha quasi alcun problema a far girare software odierno..

[joe]

Anche io su slackware 14.0 ho avuto serie difficoltà ad aggiornare chromium. E tuttora sono fermo alla versione 34.0.1847.116 (260972) che tra le altre cose dovrebbe essere una delle ultime a supportare ancora i plugin ala netscape.
Ai tempi ne avevo addirittura parlato con AlienBob (che pacchettizza chromium) chiedendo lumi. Il supporto non è praticamente più assicurato per slackware 14.0/13.37.
In soldoni, vuoi usare chromium aggiornato? Aggiorna la tua distribuzione.

Bè se salta fuori qualche idea in merito a compilazioni statiche e roba del genere benvenga, anche solo per conoscenza...
Per il resto sono d'accordo: passare ad un nuovo sistema è sempre un salto nel buio se si è impostata e personalizzata parecchia roba.
Dal canto mio comunque ormai vorrei aggiornare, ma a sto punto aspetto al prossima slackware.
...Ormai è un bel pezzo che mi ripeto questo concetto, pensavo che per pasqua o per Giugno una nuova release stabile uscisse, invece qua a sentire quanto dicevate in un altro topic ormai andiamo a finire all'autunno!

[hashbang]

Anche io su slackware 14.0 ho avuto serie difficoltà ad aggiornare chromium. E tuttora sono fermo alla versione 34.0.1847.116 (260972) che tra le altre cose dovrebbe essere una delle ultime a supportare ancora i plugin ala netscape.
Ai tempi ne avevo addirittura parlato con AlienBob (che pacchettizza chromium) chiedendo lumi. Il supporto non è praticamente più assicurato per slackware 14.0/13.37.
In soldoni, vuoi usare chromium aggiornato? Aggiorna la tua distribuzione.

Bè se salta fuori qualche idea in merito a compilazioni statiche e roba del genere benvenga, anche solo per conoscenza...

Una possibile soluzione potrebbe essere quella di capire ciò che chromium ha bisogno di aggiornato, compilarlo separatamente, e poi modificare le variabili CFLAGS ed LDFLAGS per andare a dire a chromium di pescare gli header e di linkare la libreria necessaria da un percorso differente da quello predefinito.
Da lì poi si può fare uno script wrapper che lanci il binario del browser con LD_LIBRARY_PATH.
Tuttavia c'è da considerare che:
1) non è detto che le dipendenze aggiornate richieste siano poche. Potrebbero anche essere molte;
2) Abusare di LD_LIBRARY_PATH non è mai una buona soluzione in quanto LD_LIBRARY_PATH ed LD_PRELOAD sono veri e propri buchi di sicurezza spacciati per funzionalità, perché è possibile ingannare il loader iniettando codice non previsto (ovvero librerie differenti da quelle realmente richieste) e che quindi potrebbe danneggiare il proprio sistema operativo.

In ogni caso, questo non ha nulla a che vedere con la compilazione statica. Mi riferisco anche all'autore del thread.

La compilazione statica è una cosa del tutto differente e prevede che si linkino staticamente nel codice oggetto del software i riferimenti di ogni libreria necessaria per creare un eseguibile completamente indipendente.

E considerando che in Slackware c'è una policy di rimuovere quando possibile le librerie statiche da ogni software i problemi si complicano, perché dovreste andare a compilare TUTTE le dipendenze (anche libX11 e compagnia) in versioni statiche.

Per il resto sono d'accordo: passare ad un nuovo sistema è sempre un salto nel buio se si è impostata e personalizzata parecchia roba.

E per non perdere qualche decina di minuti a mettere a punto qualche configurazione della distro siete disposti a spendere ore (se vi va bene) per far funzionare un software che richiede librerie più aggiornate.
Tra l'altro se da un lato non volete correre il rischio di dover riconfigurare la distro, dall'altro però siete disposti ad ignorare il rischio (ben più grave) di avere un sistema con falle di sicurezza non coperte. Specie se consideriamo che Slackware 12.2 è EOL da anni ormai e ci sono falle di sicurezza più o meno gravi che sono state scoperte e di cui non è certa l'immunità dei vostri sistemi (Heartbleed in OpenSSL, Shellshock in Bash, POODLE, possibili vulnerabilità nella libc e nella toolchain ecc.).
Sinceramente non so voi, ma tra i due rischi non avrei problemi a sacrificare la messa a punto della mia distribuzione.

Nessuna polemica, sia chiaro. È solo che trovo un tantino insensato il non voler aggiornare a tutti costi per non perdere due configurazioni in croce accettando di rimanere sprovvisti di patch e di supporto ad applicativi più recenti.

OffTopic. Credo questo sia uno dei "guai" di linux..... Un qualunque XP dello stesso periodo non ha quasi alcun problema a far girare software odierno..

Non è uno dei guai di Linux, ma uno dei limiti strutturali del linking dinamico e che affligge quasi tutti i sistemi mainstream presenti nel mercato.
Dico quasi tutti perché attualmente quello meno colpito è OSX che impone la compilazione statica nei suoi bundle e che quindi ha un range di runtime supportati molto più vasto.
Range facilmente ottenibile anche su Linux, se si compilasse staticamente il software. Come ho scritto sopra Linux è attualmente retrocompatibile fino alle ABI della 2.6.32, il che vuol dire che un binario statico avrebbe un range di circa 5 anni e comprendente tutte le distribuzioni esistenti.
Inoltre in caso di software a 32-bit esso potrebbe girare in un sistema a 64-bit senza la necessità di installare multilib, mantenendo quindi il sistema host pulito e privo di librerie multi-architettura che sono una delle cose a mio avviso più odiose.

Il problema è che questa politica su Linux è potenzialmente controproducente in quanto GLIBC è un cancro che crea binari statici bloat perché poco ottimizzata, e che marchia i simboli con la versione delle API rendendoli a volte incompatibili anche quando non dovrebbero esserlo.
Senza contare che non tutti i software supportano la compilazione statica.

Su Windows il problema ha un impatto inferiore, in quanto il sistema è uno e uno solo e quindi Visual C++ può ottimizzare i binari risultanti per garantire un range di compatibilità per ABI e API.
Inoltre sempre su Windows esiste la cultura del fornire le librerie dipendenti nella stessa directory del prodotto, tanto che il loader è progettato per ricercare le librerie dipendenti prima nella directory dell'eseguibile e solo dopo nelle directory di sistema.

[percoco2000]

Nessuna polemica, sia chiaro. È solo che trovo un tantino insensato il non voler aggiornare a tutti costi per non perdere due configurazioni in croce accettando di rimanere sprovvisti di patch e di supporto ad applicativi più recenti.

Non e' solo un problema di "configurazioni". Ma quando hai piu' di qualche software compilato autonomamente, o che appunto non puoi usare su distro nuove...
Nella configurazione di prima, io ho diversi emulatori compilati e configurati, con le rom al loro posto, i bios, i gamepad..etc etc.. E gia' solo azzeccare il mame con la corretta versione delle rom e' qualcosa che mi "spaventa"
Riguardo alla sicurezza, poi, e' un problema che si porrebbe su macchine "importanti" connesse H24, nessun hacker potrebbe essere interessato al mio videogame

[cressida]

puoi provare a vedere quello che ti gira dei binari di mozilla

Questo l'avevo già provato, ma niente!
@hashbang: si evidentemente la soluzione che proponi è troppo impegnativa e non credo che ne valga la pena.
Anche io come altri ho intenzione di aggiornare all'uscita della prossima versione di Slackware

Se ho capito bene una libreria può essere compilate staticamente (static library) o dinamicamente (shared library) rispetto ad altre librerie più "fondamentali" da cui dipende. Allo stesso modo un eseguibile può essere linkato staticamente o dinamicamente alle librerie.
Se compilassi firefox staticamente (magari tramite l'opzione -static di gcc che viene azionata dall' --enable-static del ./configure ???) questo non funzionerebbe per il fatto che le librerie a cui fa riferimento sono librerie condivise, e cioé dipendono dinamicamente da altre librerie.
È così?
Scusate la domanda ingenua ma non ho chiaro per niente il meccanismo!

[hashbang]

Se ho capito bene una libreria può essere compilate staticamente (static library) o dinamicamente (shared library) rispetto ad altre librerie più "fondamentali" da cui dipende. Allo stesso modo un eseguibile può essere linkato staticamente o dinamicamente alle librerie.
Se compilassi firefox staticamente (magari tramite l'opzione -static di gcc che viene azionata dall' --enable-static del ./configure ???) questo non funzionerebbe per il fatto che le librerie a cui fa riferimento sono librerie condivise, e cioé dipendono dinamicamente da altre librerie.
È così?
Scusate la domanda ingenua ma non ho chiaro per niente il meccanismo!

Non è che non funzionerebbe l'applicazione. Semplicemente fallirebbe al linking, quindi non riusciresti mai ad ottenere un binario.

Mettiamola così, spiego un po' come funziona la cosa:
Abbiamo libpippo e dobbiamo compilare l'applicazione "paperino" che dipende da essa.
Il pacchetto di libpippo fornisce un header "pippo.h" in /usr/include, che ci dà la possibilità di accedere ai prototipi delle funzioni messe a disposizione dalla libreria.
Paperino ha un #include<pippo.h> all'interno del sorgente.
Ora, in fase di linking GNU ld deve decidere cosa fare. Abbiamo due strade:

Linking dinamico (librerie condivise)
libpippo è una libreria linkata dinamicamente, quindi la nostra libreria è un binario libpippo.so.1.0.0 presente in /usr/lib(64).
GNU ld quindi si limiterà a scrivere nel codice oggetto di paperino i riferimenti ai simboli e alle funzioni descritte da libpippo e il nome della libreria necessaria (che è quello che vedi quando usi ldd).
Di conseguenza, l'eseguibile paperino sarà direttamente dipendente da libpippo.so.1.0.0.

Linking statico (librerie statiche)
libpippo è una libreria linkata staticamente, quindi la nostra libreria è un archivio AR libpippo.a presente in /usr/lib(64).
Questo archivio contiene una serie di codici oggetto (file .o) che corrispondono alle funzioni della libreria, ed il suo contenuto è visualizzabile tramite il comando

Codice: Seleziona tutto

$ ar t /usr/lib(64)/libpippo.a

GNU ld quindi andrà ad estrarre da questo archivio il codice oggetto che serve a paperino e lo unirà al codice oggetto principale, creando quindi un eseguibile che non dipenderà più da nessuna libreria, in quanto le funzioni necessarie saranno integrate direttamente nel binario.


Morale della favola: per poter compilare staticamente un binario devi assicurarti di avere versioni statiche di tutte le sue librerie dipendenti, perché in fase di linking GNU ld deve estrarre il singolo codice oggetto richiesto e linkarlo direttamente.
E come ho già scritto, in Slackware le librerie statiche vengono spesso e volentieri rimosse nello SlackBuild o comunque disattivate in fase di configure.

Quindi dovresti prendere il sorgente delle librerie, compilarle a mano e installarle in un percorso ad hoc.
Poi da lì compilare firefox dicendogli tramite CFLAGS ed LDFLAGS di linkare le librerie da quel percorso.

[Rama]

forse non ho afferrato bene, ma io da quasi sempre ho scaricato firefox da http://www.mozillaitalia.org/home/download/#firefox, quindi scompattato in una partizione che uso per i dati e linkato l'eseguibile nell'/usr/bin di ogni nuova versione della slack;
ho una memoria labile ma non ricordo di aver mai avuto problemi e si aggiorna da sé;

[cressida]

forse non ho afferrato bene, ma io da quasi sempre ho scaricato firefox da http://www.mozillaitalia.org/home/download/#firefox, quindi scompattato in una partizione che uso per i dati e linkato l'eseguibile nell'/usr/bin di ogni nuova versione della slack;
ho una memoria labile ma non ricordo di aver mai avuto problemi e si aggiorna da sé;

Ecco cosa ottengo

Codice: Seleziona tutto

$ ./run-mozilla.sh ./firefox
./firefox: symbol lookup error: /home/user/firefox/libxul.so: undefined symbol: gtk_widget_set_can_focus

Suppongo GTK troppo vecchie

Grazie hashbang molto più chiaro ora!!