Glibc, installazione da sorgenti: come si fa?

[Gica78R]

Ciao a tutti!

Apro questa discussione per un problema specifico, ma dalla quale spero potrà uscire fuori una sorta di how-to sufficientemente dettagliato.

Problema: vorrei usare l'ultima versione del programma Boinc (http://boinc.berkeley.edu/) su un sistema GNU/Linux Slackware 11. Ho scaricato il programma (binario) ma, al lancio, mi dice che non trova le glibc 2.4. Infatti su Slackware 11 sono installate le 2.3.6.

Prima domanda: esiste un comando che mi faccia sapere esattamente quale versione di una data libreria è installata sul sistema?

Vista la situazione, ho deciso di scaricare i sorgenti delle Glibc-2.4 per installarle. Leggendo le FAQ ed il file INSTALL ho capito che queste librerie sono fondamentali per il funzionamento del sistema e che una installazione non corretta potrebbe comprometterne seriamente la stabilità. Di conseguenza ho pensato che sarebbe stato opportuno installarle in una directory diversa da quella standard, in modo da mantenere come versione principale quella vecchia, rendendo disponibile la nuova versione solo a quei programmi che ne hanno bisogno. Quindi ho iniziato la configurazione e la compilazione nel modo seguente:


ho decompresso il file glibc-2.4.tar.bz2, ottenendo la directory glibc-2.4
sullo stesso livello della glibc-2.4, ho creato la directory di build glibc-2.4-build, come suggerito nell'INSTALL
spostatomi nella build directory, ho impartito il comando
$ ../glibc-2.4/configure --prefix=/usr/local/myprogs
e la configurazione è andata a buon fine
ho impartito il comando
$ make
e la compilazione non ha restituito alcun errore
ho impartito il comando
$ make check
e, dopo un po' di tempo, ho ottenuto il seguente messaggio di errore:
libgcc_s.so.1 must be installed for pthread_cancel to work
Didn't expect signal from child: got `Aborted'
make[2]: *** [/home/gianluca/src/glibc-2.4-build/nptl/tst-mutex8.out] Error 1
make[2]: Leaving directory `/home/gianluca/src/glibc-2.4/nptl'
make[1]: *** [nptl/tests] Error 2
make[1]: Leaving directory `/home/gianluca/src/glibc-2.4'
make: *** [check] Error 2


Cercando in giro, ho notato che è una cosa che capita a molti durante la compilazione di queste librerie. Il problema, a quanto sono riuscito a capire, sta nel fatto che le libgcc_s non sono di una versione compatibile con le glibc-2.4. Quindi suppongo che andrebbero prima aggiornate le libgcc_s.

Seconda domanda: cosa sono le libgcc_s, e dove le trovo? Devo per caso aggiornare lo stesso gcc?

Terza domanda: posso aggiornare tutte queste cose senza alterare la configurazione iniziale del sistema, cioè senza sostituire le librerie vecchie?

Quarta domanda:: sapreste descrivermi, non necessariamente in dettaglio, l'interdipendenza dei software citati in questa discussione tra loro e con il kernel?


Grazie :)

[ilsensine]

Prima domanda: esiste un comando che mi faccia sapere esattamente quale versione di una data libreria è installata sul sistema?
Devi usare gli strumenti di query dei pacchetti della tua distribuzione.
Per le libc è semplice, basta vedere il suffisso di /lib/ld-<versione>.so

Vista la situazione, ho deciso di scaricare i sorgenti delle Glibc-2.4 per installarle.
No, non farlo, sei ancora giovane :D

Ti consiglio vivamente di installare un'altra distribuzione con le librerie richieste su una partizione (o in una macchina virtuale, e dopo l'installazione ti copi i file in una directory locale); puoi quindi far partire il tuo programma in chroot.

[Gica78R]

No, non farlo, sei ancora giovane :D

:bimbo: :cry:

Ti consiglio vivamente di installare un'altra distribuzione con le librerie richieste su una partizione (o in una macchina virtuale, e dopo l'installazione ti copi i file in una directory locale); puoi quindi far partire il tuo programma in chroot.

Uhm... non mi piace come soluzione. La Slackware su cui sto giocherellando non è il mio sistema di lavoro, perciò la posso anche sfasciare senza troppi pensieri... quindi vedrò di capire meglio come funzionano le cose. Magari leggendo il manuale di LFS dovrei tirare fuori qualcosa di utile... :)

[eclissi83]

oh le glibc!!!
prima regola: non cambiare mai le glibc da sotto al culo alla tua distro! :)
seconda regola: non sfasciare mai una slackware (nota il cappellino :p)

Prima di iniziare, tieni presente che le glibc non son poi cosi' semplici da compilare.

Slackware usa delle glibc 2.3.6 con il supporto alle nptl oltre che linuxthreads; perche'? non perche' Pat sia fuori di melone, ma perche' son le ultime glibc a supportare il kernel 2.4. Questo il motivo per cui non e' passato ancora alle glibc 2.4.

NON puoi mantenere piu' versioni di glibc sullo stesso sistema.
Se vuoi giocare con la distro installata, beh fai pure tranquillamente l'upgrade (tra l'altro mi pare che nella current ci siano addirittura le glibc 2.5) incrociando le dita e pregando che Bob (il tizio con la pipa) non ti tenga il broncio per un po'.
Io userei lo slackbuild (lo trovi nei mirror slackware nella dir sources) del 2.5. In pratica e' come se fosse un port o un ebuild, insomma delle istruzioni per compilare e fare il pacchetto, ovviamente _senza_ risolvere alcuna eventuale dipendenza (evviva slackware!).

Per l'errore da te segnalato, devi aggiornare anche il gcc perche' credo siano cambiate alcune delle api dalla 3.4 alla 4.

P.S.: quando compilerai le glibc (e poi tutta la distro) sul tuo portatile con il supporto all'altivec sentirai la vera potenza dei powerpc... ah, no, scusa, tu usi debian :p
P.P.S: hai la firma irregolare... "Sappiate che ad ogni nuova release dei driver proprietari nVidia per Linux, dio ammazza un micetto!"

[Johnn]

Anche io ti sconsiglio di compilarti (per ora) le glibc! Confermo quanto detto da eclissi83 sul fatto che puoi scaricarti il tgz con le glibc 2.5 (che attualmente uso nel mio pc). E' un aggiornamento delicato, quindi un back-up non fa male. Se devi aggiornare alla current anche altri componenti importanti del sistema, aggiorna prima le glibc! Per aggiornare un qualsiasi pacchetto basta fare:

upgradepkg nome_pacchetto

Per vedere che versione hai di qualsiasi programma basta che lanci da root "pkgtool" e scegli "view".


P.S. La cosa più :sbav: della ricompilazione delle glibc è che potresti avvertire i veri vantaggi prestazionali di una compilazione ad hoc per la tua macchina, almeno da quanto ho sentio in giro.

[Gica78R]

Scusate la prolungata assenza... sto provando a costruire un sistema LFS e, ora che sono a buon punto, riprovo a modificare anche la Slack.


oh le glibc!!!
prima regola: non cambiare mai le glibc da sotto al culo alla tua distro! :)
seconda regola: non sfasciare mai una slackware (nota il cappellino :p)

Ricevuto! :)


Slackware usa delle glibc 2.3.6 con il supporto alle nptl oltre che linuxthreads; perche'? non perche' Pat sia fuori di melone, ma perche' son le ultime glibc a supportare il kernel 2.4. Questo il motivo per cui non e' passato ancora alle glibc 2.4.

Ok... io non ho bisogno del kernel 2.4 :p

NON puoi mantenere piu' versioni di glibc sullo stesso sistema.

Uhm... quindi non posso crearmi un utente che si installi una specie di "sottosistema", con librerie, compilatore, linker e roba varia da usare indipendentemente da quanto presente sul sistema? :(

Per l'errore da te segnalato, devi aggiornare anche il gcc perche' credo siano cambiate alcune delle api dalla 3.4 alla 4.

Ok, grazie :)

P.P.S: hai la firma irregolare... "Sappiate che ad ogni nuova release dei driver proprietari nVidia per Linux, dio ammazza un micetto!"

Eh, ma come l'avevo scritta io faceva più ridere! :p E poi, nel caso specifico si tratta della stessa persona! :D


Ciao

[eclissi83]

Scusate la prolungata assenza... sto provando a costruire un sistema LFS e, ora che sono a buon punto, riprovo a modificare anche la Slack.

ottimo! fa bene alla salute farsi una LFS, si scoprono un sacco di fatti.


Uhm... quindi non posso crearmi un utente che si installi una specie di "sottosistema", con librerie, compilatore, linker e roba varia da usare indipendentemente da quanto presente sul sistema? :(

si ma devi crearti una specie di ambiente chrootato.


Eh, ma come l'avevo scritta io faceva più ridere! :p E poi, nel caso specifico si tratta della stessa persona! :D

anche questo è vero.

Ciao
ciao!

[Gica78R]

Ok, sono arrivato alla ragionevole conclusione che sostituire le Glibc-2.3.6 con le 2.4 su un sistema in uso è praticamente impossibile, nonché quasi sicuramente distruttivo! :(

Purtroppo non sono riuscito a mettere le 2.4 nemmeno sul sistema LFS che stavo costruendo; infatti seguivo LFS-6.2, che fa ancora riferimento alle Glibc-2.3.6, ma ho cercato di andare per la mia strada installando software più recente di quello riportato dalla guida. Morale? Le Glibc-2.4 mi davano errori in compilazione. :cry:


A questo punto, però, vorrei provare a sostituire le Glibc-2.3.6 già presenti sul sistema, precompilate per 486, con la stessa versione ma compilata specificamente per il mio processore. Come devo procedere su Slackware? C'è un modo di fare "pulito", una procedura standard? Dove posso trovare le informazioni circa le modalità, le opzioni e gli add-ons usati nel package ufficiale?

Grazie

[gurutech]

Ok, sono arrivato alla ragionevole conclusione che sostituire le Glibc-2.3.6 con le 2.4 su un sistema in uso è praticamente impossibile, nonché quasi sicuramente distruttivo! :(


operazione comunemente chiamata: come incartare il sistema in 1,27 picosecondi con un "make install" :D

tieni presente che OGNI eseguibile sul tuo sistema è linkato con le glibc.
ad esempio in /bin trovi

find /bin -type f -exec ldd '{}' ';' | grep libc\.so | wc -l

eseguibili linkati alle glibc. nell'istante in cui le cambi smetteranno tutti di funzionare da /bin/ls a /bin/touch e compagnia bella!

[Gica78R]

Io userei lo slackbuild

Vorrei usare lo slackbuild per ricompilare semplicemente le Glibc-2.3.6 per il mio processore. L'ho trovato sul dvd di installazione di Slackware 11. Al suo interno viene definita la variabile di ambiente ARCH nel seguente modo:

ARCH=${ARCH:-i486}

Quindi, se non è già definita, essa assume il valore -i486. Di seguito, tale variabile viene usata per definire la variabile OPTIMIZ:

# I'll break this out as an option for fun :-)
if [ "$ARCH" = "i386" ]; then
OPTIMIZ="-O3 -march=i386 -mcpu=i686"
elif [ "$ARCH" = "i486" ]; then
OPTIMIZ="-O3 -march=i486 -mtune=i686"
elif [ "$ARCH" = "i586" ]; then
OPTIMIZ="-O3 -march=i586"
elif [ "$ARCH" = "i686" ]; then
OPTIMIZ="-O3 -march=i686"
elif [ "$ARCH" = "athlon" ]; then
OPTIMIZ="-O3 -march=athlon"
elif [ "$ARCH" = "s390" ]; then
OPTIMIZ="-O3"
elif [ "$ARCH" = "x86_64" ]; then
OPTIMIZ="-O3"
else
OPTIMIZ="-O3"
fi

che a sua volta influirà sul valore di CFLAGS.

Allora, io vorrei compilare per Pentium 3, quindi vorrei che nella CFLAGS ci fossero le opzioni -O3 e -march=pentium3. Definendo però la variabile ARCH=-i686 la variabile CFLAGS assumerebbe le opzioni -O3 e -march=i686 invece di pentium3. Che faccio, modifico lo script o vado bene anche con i686? E il livello di ottimizzazione -O3 è sicuro o è meglio scegliere -O2 o -Os?
Ultimissima cosa: posso lanciare lo slackbuild direttamente dal dvd (dove ci sono già tutti i sorgenti e le patch) oppure no, perché tenterebbe di creare la directory di build nella directory source del dvd?


Grazie


PS: inizia a piacermi 'sta cacchio di Slack! :p
PS2: non mi sono ancora molto chiare le differenze tra le opzioni -march, -mcpu, -mtune di gcc :stordita:

[eclissi83]

Allora, io vorrei compilare per Pentium 3, quindi vorrei che nella CFLAGS ci fossero le opzioni -O3 e -march=pentium3. Definendo però la variabile ARCH=-i686 la variabile CFLAGS assumerebbe le opzioni -O3 e -march=i686 invece di pentium3. Che faccio, modifico lo script o vado bene anche con i686? E il livello di ottimizzazione -O3 è sicuro o è meglio scegliere -O2 o -Os?

puoi modificare lo script tranquillamente, solo che se le glibc essendo abbastanza delicate forse e' meglio non ottimizzarle troppo. io andrei di -Os e -march=i686

Ultimissima cosa: posso lanciare lo slackbuild direttamente dal dvd (dove ci sono già tutti i sorgenti e le patch) oppure no, perché tenterebbe di creare la directory di build nella directory source del dvd?

no cerca di scrivere sulla dir da cui lo lanci, quindi copia lo slackbuild in una dir qualsiasi, tanto ti crea il pacchetto li' dentro.


Grazie

prego!


PS: inizia a piacermi 'sta cacchio di Slack! :p

malfidato che non sei altro! :)

PS2: non mi sono ancora molto chiare le differenze tra le opzioni -march, -mcpu, -mtune di gcc :stordita:
http://gentoo-wiki.com/Safe_Cflags e http://gentoo-wiki.com/CFLAGS ... i bimbi gentu' servono a qualcosa :p

[Gica78R]

Ok, sono arrivato alla ragionevole conclusione che sostituire le Glibc-2.3.6 con le 2.4 su un sistema in uso è praticamente impossibile, nonché quasi sicuramente distruttivo! :(

Ma siccome sono testardo, lo voglio fare ugualmente... :fagiano:
Ho capito che la compilazione delle Glibc è molto diversa dalla compilazione di una semplice applicazione, e che per farlo bisogna prima costruirsi un ambiente dotato di vari strumenti, tra cui un assembler, un linker, un compilatore, ecc... che funzionino indipendentemente dagli strumenti già presenti nel sistema. Qualcuno potrebbe chiarirmi meglio questo fatto? Quali sono le dipendenze (se così le possiamo chiamare) da soddisfare prima di compilare le Glibc? Nel manuale di Linux From Scratch, prima di compilare le Glibc si installano, in una directory locale:

le binutils
il compilatore (con il solo supporto al linguaggio C)
gli header del kernel

Però in questo caso l'intenzione è quella di creare un ambiente minimale indipendente dal sistema in esecuzione, in modo tale da costruire il successivo sistema del tutto scollegato dal sistema "ospite". Ma nel caso di sostituzione delle Glibc sul sistema corrente la procedura è sempre questa? Oppure, dato che non dobbiamo costruire un sistema ex-novo si procede diversamente?


Grazie :)

[eclissi83]

Ma siccome sono testardo, lo voglio fare ugualmente... :fagiano:
Ho capito che la compilazione delle Glibc è molto diversa dalla compilazione di una semplice applicazione, e che per farlo bisogna prima costruirsi un ambiente dotato di vari strumenti, tra cui un assembler, un linker, un compilatore, ecc... che funzionino indipendentemente dagli strumenti già presenti nel sistema. Qualcuno potrebbe chiarirmi meglio questo fatto? Quali sono le dipendenze (se così le possiamo chiamare) da soddisfare prima di compilare le Glibc? Nel manuale di Linux From Scratch, prima di compilare le Glibc si installano, in una directory locale:

le binutils
il compilatore (con il solo supporto al linguaggio C)
gli header del kernel

Però in questo caso l'intenzione è quella di creare un ambiente minimale indipendente dal sistema in esecuzione, in modo tale da costruire il successivo sistema del tutto scollegato dal sistema "ospite". Ma nel caso di sostituzione delle Glibc sul sistema corrente la procedura è sempre questa? Oppure, dato che non dobbiamo costruire un sistema ex-novo si procede diversamente?


Grazie :)
la procedura "giusta" per mettere delle nuove glibc sarebbe quella di ricompilare tutto il sistema base... quindi, si, diciamo che devi fare come dice il libro di LFS..

buon lavoro amicoide! :)