joe ha scritto: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.
percoco2000 ha scritto: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.
