Perché FreeBSD sta deprecando GCC a favore di Clang / LLVM?


241

Quindi stavo navigando in rete e mi sono imbattuto in questo articolo . Sostanzialmente afferma che FreeBSD , a partire dalla versione 10 e successive, deprecherà GCC a favore di Clang / LLVM .

Da quello che ho visto finora in rete, Clang / LLVM è un progetto abbastanza ambizioso, ma in termini di affidabilità non può eguagliare GCC .

Ci sono ragioni tecniche per cui FreeBSD sta scegliendo LLVM come propria infrastruttura di compilatore o l'intera questione si riduce alle eterne licenze GNU / GPL vs. BSD?

Questa domanda contiene (in qualche modo) informazioni rilevanti sull'uso di GCC in FreeBSD

Risposte:


361

Riepilogo: Il motivo principale per passare da GCC a Clang è l'incompatibilità della licenza GPL v3 di GCC con gli obiettivi del progetto FreeBSD . Ci sono anche questioni politiche a che fare con gli investimenti aziendali, così come i requisiti della base di utenti. Infine, ci sono dei vantaggi tecnici attesi dalla conformità agli standard e dalla facilità di debug. I miglioramenti delle prestazioni del mondo reale nella compilazione e nell'esecuzione sono specifici del codice e discutibili; i casi possono essere fatti per entrambi i compilatori.

FreeBSD e la GPL: FreeBSD ha una relazione difficile con la GPL. I sostenitori della licenza BSD ritengono che il software veramente gratuito non abbia restrizioni d'uso . I sostenitori della GPL ritengono che siano necessarie restrizioni al fine di proteggere la libertà del software, e in particolare che la capacità di creare software non libero dal software libero è una forma ingiusta di potere piuttosto che una libertà. Il progetto FreeBSD, ove possibile, cerca di evitare l'uso della GPL :

A causa delle complessità aggiuntive che possono evolversi nell'uso commerciale del software GPL, tuttavia, ci sforziamo di sostituire tale software con invii sotto la licenza più rilassata di FreeBSD ogni volta che è possibile.

FreeBSD e la GPL v3: La GPL v3 proibisce esplicitamente la cosiddetta tivoizzazione del codice, una scappatoia nella GPL v2 che ha permesso alle restrizioni hardware di impedire modifiche software altrimenti legali da parte degli utenti. Chiudere questa scappatoia è stato un passaggio inaccettabile per molti nella comunità di FreeBSD:

In particolare, i fornitori di apparecchiature hanno più da perdere se la vasta gamma di software attualmente in licenza con GPLv2 passa oggi alla nuova licenza. Non avranno più la libertà di usare il software GPLv3 e limitare la modifica del software installato sul loro hardware ... In breve, c'è una vasta base di consumatori OpenSource che sono improvvisamente molto interessati a capire le alternative al software con licenza GPL.

A causa del passaggio di GCC a GPL v3, FreeBSD è stato costretto a rimanere usando GCC 4.2.1 (GPL v2), che è stato rilasciato nel 2007 , e ora è notevolmente obsoleto. Il fatto che FreeBSD non si sia mosso per usare versioni più moderne di GCC, anche con il mal di testa di manutenzione aggiuntivo di eseguire un vecchio compilatore e correzioni di backport, dà un'idea della forza del requisito per evitare GPL v3. Il compilatore C è un componente importante della base di FreeBSD e " uno degli obiettivi (indicativi) di FreeBSD 10 è un sistema di base privo di GPL ".

Investimenti aziendali: come molti dei principali progetti open source, FreeBSD riceve finanziamenti e attività di sviluppo dalle aziende. Sebbene la misura in cui FreeBSD sia finanziato o dato dallo sviluppo da parte di Apple non sia facilmente individuabile, vi è una considerevole sovrapposizione poiché il sistema operativo Darwin di Apple utilizza un sostanziale codice kernel originato da BSD . Inoltre, lo stesso Clang era originariamente un progetto Apple interno, prima di essere open source nel 2007 . Dato che le risorse aziendali sono un fattore chiave per il progetto FreeBSD, soddisfare le esigenze degli sponsor è probabilmente un fattore determinante per il mondo reale .

Base utente: FreeBSD è un'opzione attraente open source per molte aziende, perché la licenza è semplice, senza restrizioni e probabilmente non porta a azioni legali. Con l'arrivo di GPL v3 e le nuove disposizioni anti-tivoisation , è stato suggerito che c'è una tendenza accelerata, guidata dai fornitori, verso licenze più permissive . Poiché il vantaggio percepito da FreeBSD per le entità commerciali risiede nella sua licenza permissiva, vi è una crescente pressione da parte della base di utenti aziendali per allontanarsi da GCC e dalla GPL in generale.

Problemi con GCC: oltre alla licenza, l'utilizzo di GCC presenta alcuni problemi percepiti . GCC non è completamente conforme agli standard, e ha molte estensioni che non si trovano nella norma ISO C . Con oltre 3 milioni di righe di codice, è anche " uno dei progetti software più complessi e gratuiti / open source ". Questa complessità rende complessa la modifica del codice a livello di distro.

Vantaggi tecnici: Clang presenta alcuni vantaggi tecnici rispetto a GCC . I più importanti sono i messaggi di errore molto più informativi e un'API esplicitamente progettata per gli IDE, gli strumenti di refactoring e di analisi del codice sorgente. Sebbene il sito Web di Clang presenti grafici che indicano una compilazione e un utilizzo della memoria molto più efficienti, i risultati del mondo reale sono abbastanza variabili e sostanzialmente in linea con le prestazioni di GCC. In generale, i binari prodotti da Clang funzionano più lentamente rispetto ai binari GCC equivalenti:

Mentre usare LLVM è più veloce nella costruzione del codice di GCC ... nella maggior parte dei casi i binari compilati di GCC 4.5 avevano prestazioni migliori di LLVM-GCC o Clang ... nel resto dei test le prestazioni erano vicine a quelle di GCC o bene dietro a. In alcuni test, le prestazioni dei binari generati da Clang erano semplicemente orribili.

Conclusione: è altamente improbabile che l'efficienza della compilazione sia una motivazione significativa per correre il rischio sostanziale di spostare un grande progetto come FreeBSD in una toolchain di compilatore completamente nuova, in particolare quando mancano le prestazioni binarie. Tuttavia, la situazione non era davvero sostenibile. Data la scelta tra 1) eseguire un GCC obsoleto, 2) Passare a un GCC moderno ed essere costretto a utilizzare una licenza incompatibile con gli obiettivi del progetto o 3) passare a un compilatore con licenza BSD stabile, la decisione era probabilmente inevitabile. Tieni presente che questo vale solo per il sistema di base e supporto dalla distribuzione; nulla impedisce a un utente di installare e utilizzare un GCC moderno sulla propria casella FreeBSD.


4
Il punto di riferimento che hai citato proviene da una vecchia versione di Clang. I parametri di riferimento per le versioni recenti sembrano essere le versioni recenti sono più vicini. La mia ricerca per programmi semplici ha portato Clang 3.0 un paio di volte più veloce di GCC 4.6, ma GCC era più veloce del 20% sulla versione thread. phoronix.com/scan.php?page=news_item&px=MTA5Nzc è un nuovo benchmark Phoronix.
Sean,

6
"GCC non è pienamente conforme agli standard": non è possibile utilizzare gli switch del compilatore per imporre la conformità a un determinato standard?
Giorgio,

4
Prima di tutto non leggere troppo nei benchmark di Phoronix, o piuttosto non leggerli affatto. In secondo luogo, è vero che GCC non è completamente conforme agli standard per impostazione predefinita, a meno che non si specifichi esplicitamente uno standard, in caso contrario saranno abilitate anche le estensioni GNU, ma questo sembrerebbe uno strano motivo per usare Clang invece, dal momento che anche loro stanno implementando le estensioni GNU più comunemente utilizzate perché si sforzano che Clang sia utilizzabile come calo in sostituzione di GCC.
kyrias,

1
@Giorgio: No. Vedi gcc.gnu.org/c99status.html per un esempio - e questo è solo C99 (che ora ha 14 anni). Anche gcc.gnu.org/onlinedocs/libstdc++/manual/status.html - clang ha un supporto migliore per entrambi (penso che sia pieno - e in caso contrario, è sicuramente almeno migliore).
Tim Čas,

4
@Demizey Non sto difendendo Phoronix, ma se hai intenzione di licenziare qualcosa dovresti almeno fornire un motivo valido.
Mario,

38

Una cosa da considerare è che FreeBSD sta attualmente usando GCC 4.2.1 come indicato nella risposta di ire_and_curses, quindi i confronti delle prestazioni non sono di 4.5 o addirittura 4.6 non sono realmente rilevanti per il progetto. Pertanto, le domande che dovresti porre sono:

  1. Quali sono i guadagni in termini di prestazioni del nuovo Clang rispetto al vecchio GCC utilizzato dal progetto?

  2. Come si confrontano gli stessi binari compilati in GCC 4.2.1 con il nuovo Clang?

A causa del passaggio di GCC a GPL v3, FreeBSD è stato costretto a rimanere usando GCC 4.2.1 (GPL v2), che è stato rilasciato nel 2007, e ora è notevolmente obsoleto.

Se Clang è in ritardo rispetto all'attuale GCC ma è ancora anni luce avanti rispetto al GCC implementato nel progetto, la sua decisione di evolversi è ben giustificata e veramente ispirata.


19

Anche se GCC è GPLv3, i binari risultanti prodotti da GCC non hanno mai avuto vincoli di licenza. Chiaramente puoi usare GCC per creare software che rientri nella licenza che desideri. Anche la libreria C fornita con GCC e inclusa nel file binario è senza licenza. http://www.gnu.org/licenses/gcc-exception-faq.html

Sezione 2 di GNU GPLv3:

Hai il permesso di propagare un'opera di codice target formata combinando la libreria di runtime con moduli indipendenti, anche se tale propagazione violerebbe altrimenti i termini di GPLv3, a condizione che tutto il codice target sia stato generato da processi di compilazione idonei. È quindi possibile trasmettere una tale combinazione in base alla propria scelta , in linea con la licenza dei moduli indipendenti.

"Idoneo" significa che la compilazione non comprende software incompatibili con GCC e GPL. Non è una limitazione: il software con licenza BSD può essere utilizzato nel processo di compilazione che coinvolge GNU GCC.

Come puoi vedere, contrariamente a quanto detto sopra, non esiste alcun motivo REALE legato alla licenza per allontanarsi da GCC in quanto non vi è incompatibilità con l'uso di GCC all'interno di FreeBSD.

La vera ragione di questo cambiamento è politica e opportunistica:

  • BSD ha una propria licenza che compete filosoficamente con la licenza GNU Public (come * ire_and_curses * spiegato sopra),
  • CLANG è un nuovo compilatore non GPL avviato da uno sponsor di FreeBSD che sembra tecnicamente equivalente al GCC con licenza GPL (come descritto sopra da * ire_and_curses *).

Questi fatti creano un'opportunità per FreeBSD di allontanarsi da GCC e liberarsene: in realtà non sono obbligati legalmente, in quanto potrebbero comunque usare GCC per costruire software libero o con licenza BSD, ma vogliono attenersi al filosofia "tutti i software con licenza BSD".


5
Mi dispiace, ho dovuto votare questo verso il basso. Sfortunatamente la tua non familiarità con BSD e software mostra minimi. Solo per la cronaca, è stata una decisione politica non tecnica che ha portato i BSD a passare dal tradizionale Portable C Compiler (PCC) a GCC nei primi anni novanta. Clang è il progetto Apple! Come qualcuno che usa GCC su base giornaliera per vivere su OpenBSD che sta tentando di tornare a PCC, ti sbagli in tutti gli account.
Predrag Punosevac,

5
Non si tratta dei binari risultanti, si tratta del fatto che gcc fa parte di FreeBSD - quindi i vincoli della licenza sono importanti.
sstn

3
Se la religione del progetto dice "No GPLv3", gli aspetti tecnici svaniscono - immagina di usare un compilatore Microsoft.
Thorbjørn Ravn Andersen,

3
Questa è l'unica risposta che lo indica correttamente license of compiler != license of end product. Reclami su una licenza del compilatore non possono essere rilevanti a meno che l'utente non capisca la licenza.
Brandin,

6
Non si tratta di stabilire se i file binari prodotti rientrano in GPLv3, ma se le modifiche al compilatore stesso richiedono la conformità GPLv3. I fornitori di hardware spesso modificano il compilatore di stock per lavorare meglio con il proprio hardware o sfruttare l'hardware in modo proprietario. Rimuovere il rischio che le modifiche personalizzate debbano essere conformi a GPLv3 o il rischio di azioni legali è un grosso problema per tali organizzazioni. È davvero la licenza del compilatore che conta qui.
David Harks,

7

Non sono un esperto, ma la mia comprensione è che Clang / LLVM utilizza meno risorse di GCC ed è più veloce.

http://clang.llvm.org/features.html#performance

Se si esegue un ambiente in cui è necessario creare molte cose, molte volte, tali prestazioni potrebbero trasformarsi in risparmi reali in termini di costi e tempi energetici. Se è reale.


Minori .. e ci sono strumenti per ridurre ulteriormente i tempi di compilazione ripetitivi - ccache.samba.org Non importa le ovvie possibilità di compilazione parrallel (vedi distcc), i tempi di collegamento tendono ad essere più difficili da risolvere in grandi progetti
Rob11311

Sì, molto bene, ma il codice binario risultante è più lento; p
rustyx,

1
@rustyx non rispetto a gcc 4.2!
Miles Rout
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.