linux user group brescia

> 
> At 16.52 29/03/01 +0200, Carlo Remino wrote:
> 
> >Ok, so che a leggere quello che seguira' una meta' di voi si sbellichera' 
> >dal ridere e l' altra meta' si domandera' se sogna o e' desta, ma qualcuno 
> >avrebbe la bonta' di spiegarmi che cos' e' 'sta glibc, a che cosa serve e 
> >perche' se ne va in giro con tanti nomi diversi ?
> 
> http://www.gnu.org/software/libc/libc.html
> 
La libc e' la libreria di funzioni `standard' cui ricorrono praticamente
 tutti i programmi sul sistema, anche quelli che in C non sono scritti;
 teoricamente sarebbe possibile scrivere del codice che non passa
 attraverso la libc (in assembler o altro) e utilizza direttamente le
 chiamate di sistema (ad es. per stampare una stringa, piuttosto che
 per creare un file), ma la cosa e' poco pratica e poco portabile.

Perche' tutti i nomi? Il motivo e' semplice: la libc e' parte integrante
 ed essenziale di un sistema Unix-like e -nel caso di linux- ha subito 
 diverse `incarnazioni', in concomitanza con l'evoluzione del kernel e
 del sistema in generale. Quelle che io ho elencato sopra sono le 
 `generazioni' piu' importanti:

 libc4 -> in formato binario "a.out" ... questo e' il formato usato dagli
         eseguibili sotto linux per il kernel 1.0 e che e' stato impiegato
         per lungo tempo anche con lo 1.2. Lasciato in favore di `ELF'
         (il formato corrente) per problemi nella creazione delle librerie
         dinamiche e una scarsa flessibilita' dell'implementazione. 
         Per intenderci, la differenza fra una libreria in formato "a.out"
        e una in formato "ELF" e' piu' o meno la stessa che c'e' fra una
         ".dll" o un programma ".exe" e una libreria sotto linux.

libc5 -> libc in formato ELF; standard (ad esempio) con RH5.x o SlackWare 4.
         E' un porting altamente modificato della libc4... non sono 
         compatibili (per ovvi motivi). Su un sistema ci possono essere libc4
         e libc5... la 4 per i programmi in formato "a.out" e la 5 per quelli
         in formato "ELF". Nessun problema di coesistenza (a parte lo spazio
         e la memoria sprecati).

libc6 aka glibc2 -> riscrittura da zero della libc... ha richiesto piu'
                    di 2 anni ed e' finalizzata fra le altre cose a
                   1. incorporare il supporto per l'internazionalizzazione;
                   2. fornire accesso alle nuove funzionalita' del kernel;
                   3. offrire, fra le altre cose, chiamate di funzioni 
                      rientranti (per il multithread);
                   4. evitare future incompatibilita'.
                    Anche questa NON e' compatibile con la libc5 ma il
                    linker dinamico puo' far coesistere programmi compilati
                    con la 5 e programmi compilati con la 6. Il sacrificio
                    della compatibilita' diretta con la 5 e' stato 
                    intenzionale.

Fra gli obiettivi della glibc2, i punti 1,2 e 3 sono stati raggiunti senza
 troppo dolore... il 4, ahime' no [se si vuole si puo' dare la colpa a RH
 di aver rilasciato la sua versione 6.0 con una libreria non ancora troppo
 stabilizzata; d'altro canto se RH non l'avesse fatto, ben difficilmente
 ci sarebbe stata una base di utenti abbastanza grande da provare il tutto].

In pratica la glibc2.1 NON e' compatibile con la glibc2.0 dal punto di vista
 binario e le due NON possono coesistere sul medesimo sistema (a meno di
 sporchi trucchi... trucchi tanto sporchi da non essere opportuni); una
 brutta cosa. La glibc2.2 (quella attualmente inclusa con RH7) e' una
 risistemazione dei problemi derivanti dalla 2.0/2.1 ma -nuovamente- viene
 sacrificata buona parte della compatibilita' binaria (un 30% di applicazioni
 compilate per la 2.{0,1} sotto 2.2 non vanno); comunque pare che questa
 sia la volta buona, modulo avere una glibc2.2 STABILE!

Ciao,
 lg