Visto che questo nelle mie intenzioni originali doveva essere un blog tecnico, perlomeno un post pseudo-tecnico ogni tanto mi prae il caso di farlo. È di oggi la notizia che Sun Microsystems conferma le voci a riguardo del rilascio opensource di Solaris.
Ottima cosa, senza dubbio, anche se il mio amico limaCAT espone dei dubbi sul tipo di licenza che Sun potrà usare, io propendo per una versione modificata della BSD License, che impedisca l’uso commerciale delle versioni modificate di quel software.
Proprio a riguardo dell’articolo succitato, vorrei citare una frase del COO di Sun:
“There is a big difference between both (open source and open standards). There is one Linux company in the world today that’s confusing the two concepts, and that is Red Hat. And it is very dangerous,” said Schwartz.
Mi ha molto colpito questo fatto, e in maniera favorevole. È vero che Redhat abbia sempre tentato di fare i propri comodi a volte riuscendo anche a creare molti malfunzionamenti e incompatibilità. Credo che molte persone siano a conoscenza del quantitativo di problemi creati da GCC 2.96, per chi ignorasse questa storia, credo sia giusto fare un piccolo riassunto.
Nei tempi precedenti il rilascio di GCC 3.0 (cioè prima del passaggio di EGCS/GNU C Compiler a Gnu Compiler Collection), l’ultima versione stabilizzata di GCC era la 2.95. Questa versione aveva qualche piccolo problema in certe implementazioni del C++ e del C standard, che rendevano difficili, se non impossibili, da compilare dei sorgenti scritti usando le sintassi definite dallo standard (un po’ come succede con Microsoft Visual C++), ma solo quando usassero sintassi veramente poco comuni, oppure le std::w_string (che non sono presenti di default sul 2.95). GCC 2.96 non uscì mai ufficialmente, infatti dopo l’ultima service release del 2.95 è stato rilasciato GCC 3.0 final, fino ad arrivare all’attuale GCC 3.4. Ma vediamo le cose dal punto di vista di uno sviluppatore a caso (io).
Nel periodo ‘di passaggio’, in cui ancora la maggior parte delle distribuzioni non includevano GCC 3, io stavo lavorando come sviluppatore presso il progetto NoX-Wizard (un salutone a Luxor per quanto anche lui se ne sia andato (e prima di me), che resta comunque un mio punto di riferimento), e tra le tante cose che stavo facendo mi ero preso l’incarico di attivare (visto che non erano mai stati attivati prima) i Warning del compilatore e di fixarli, sia su GCC che su Borland C++ Builder 6 (dimenticavo, ho curato anche il porta a BCB6, visto che fino a prima veniva utilizzato solo VC++6 con STLport; questo lavoro, ad ogni modo, è stato abbastanza semplice visto che BCB6 includeva già STLport come libreria standard, e dal 5 al 6 la sintassi accettata dal compilatore era nettamente migliorata). Il problema veniva quando mi arrivavano segnalazioni che fixando un determinato warning, il progetto non compilava più sotto Linux.
A volte si trattava di sintassi modificate, che richiedevano una compilazione condizionata con gli #ifdef, ma a volte c’erano problemi assurdi, tipo crash impossibili su linee di commento, o cose del genere. Oltre al fatto che la dimensione dell’eseguibile (anche non staticizzato) erano improponibili.
Infine, sono giunto al nocciolo del problema: GCC 2.96 cominciava a impazzire per l’imponente uso di OOP all’interno del progetto (che andava sempre aumentando), e la grandezza dell’eseguibile cresceva in maniera esponenziale. GCC 2.95 riusciva, con qualche compilazione condizionata, a gestire tutto molto bene, e a genereare un eseguibile anche più piccolo di quello del GCC 3.0. Abbiamo dovuto esplicitamente bloccare l’uso di GCC 2.96 per la compilazione del progetto.
Il punto ora è: se GCC 2.96 non è mai stato rilasciato ufficialmente, da dove spunta fuori? Ovviamente da RedHat! Era una versione di GCC 2.95 modificata con diversi backport del 3.0 e con delle modifiche alla libreria standard. Non so bene in cosa consistessero tali modifiche, ma so solo che molte sintassi non funzionavano, o lavoravano in modo diverso, e che la grandezza degli esebuibili era almeno quattro volte quella degli stessi sorgenti compilati nello stesso modo con GCC 2.95.
Per nota di cronaca, dopo un certo periodo abbiamo abbandonato anche GCC 2.95, richiedendo completamente l’uso di GCC 3.0 perché il supporto alla libreria standard del 3 è nettamente migliorato rispetto al 2.95, e per esempio std::hash_table non ne voleva sapere di funzionare senza memory leak sul 2.95. Per lo stesso motivo abbiamo anche obbligato all’uso di STLport con Visual C++ 6 (prima era possibile compilare la versione di debug senza).
Uhm, beh vediamo se prima o poi riesco a renderlo tecnico davvero ‘sto blog eh?