Por que o FreeBSD está obsoleta no GCC em favor do Clang / LLVM?


241

Então, eu estava navegando na net e me deparei com este artigo . Ele basicamente afirma que o FreeBSD , a partir da versão 10 e posterior, depreciará o GCC em favor do Clang / LLVM .

Pelo que vi na rede até agora, o Clang / LLVM é um projeto bastante ambicioso, mas em termos de confiabilidade, ele não pode corresponder ao GCC .

Há alguma razão técnica para o FreeBSD escolher o LLVM como sua infraestrutura de compilador, ou o assunto se resume às eternas licenças GNU / GPL vs. BSD?

Esta questão possui (de alguma forma) informações relevantes sobre o uso do GCC no FreeBSD

Respostas:


361

Resumo: O principal motivo para mudar do GCC para o Clang é a incompatibilidade da licença GPL v3 do GCC com os objetivos do projeto FreeBSD . Há também questões políticas relacionadas ao investimento corporativo, bem como requisitos de base de usuários. Finalmente, existem vantagens técnicas esperadas relacionadas à conformidade com os padrões e à facilidade de depuração. As melhorias de desempenho do mundo real na compilação e execução são específicas do código e discutíveis; casos podem ser feitos para ambos os compiladores.

FreeBSD e a GPL: O FreeBSD tem um relacionamento desconfortável com a GPL. Os defensores da licença BSD acreditam que o software verdadeiramente livre não tem restrições de uso . Os advogados da GPL acreditam que são necessárias restrições para proteger a liberdade de software e, especificamente, que a capacidade de criar software não livre a partir de software livre é uma forma injusta de poder, e não de liberdade. O projeto FreeBSD, sempre que possível, tenta evitar o uso da GPL :

Devido às complexidades adicionais que podem evoluir no uso comercial do software GPL, nos esforçamos, no entanto, por substituir esse software por envios sob a licença mais relaxada do FreeBSD, sempre que possível.

FreeBSD e a GPL v3: A GPL v3 proíbe explicitamente a chamada Tivoização de código, uma brecha na GPL v2 que permitiu que restrições de hardware proibissem modificações de software legais pelos usuários. Fechar essa brecha foi um passo inaceitável para muitos na comunidade FreeBSD:

Os fornecedores de equipamentos, em particular, têm mais a perder se o grande corpo de software atualmente licenciado sob a GPLv2 hoje migrar para a nova licença. Eles não terão mais liberdade para usar o software GPLv3 e restringir a modificação do software instalado em seu hardware ... Em suma, existe uma grande base de consumidores de código aberto que, de repente, estão muito interessados ​​em entender alternativas ao software licenciado pela GPL.

Devido à mudança do GCC para a GPL v3, o FreeBSD foi forçado a continuar usando o GCC 4.2.1 (GPL v2), que foi lançado em 2007 e agora está significativamente desatualizado. O fato de o FreeBSD não ter se mudado para usar versões mais modernas do GCC, mesmo com as dores de cabeça adicionais de manutenção da execução de um compilador antigo e correções de backport, dá uma idéia da força do requisito para evitar a GPL v3. O compilador C é um componente importante da base do FreeBSD e " um dos objetivos (provisórios) do FreeBSD 10 é um sistema de base livre de GPL ".

Investimento corporativo: Como muitos dos principais projetos de código aberto, o FreeBSD recebe trabalho de financiamento e desenvolvimento de empresas. Embora a extensão em que o FreeBSD seja financiado ou tenha sido desenvolvido pela Apple não seja fácil de descobrir, há uma sobreposição considerável porque o Darwin OS da Apple faz uso de um substancial código do kernel originário do BSD . Além disso, o próprio Clang era originalmente um projeto interno da Apple, antes de ser de código aberto em 2007 . Como os recursos corporativos são um facilitador essencial do projeto FreeBSD, atender às necessidades dos patrocinadores é provavelmente um fator significativo no mundo real .

Base de usuários: O FreeBSD é uma opção atraente de código aberto para muitas empresas, porque o licenciamento é simples, irrestrito e improvável que leve a processos judiciais. Com a chegada da GPL v3 e as novas disposições anti-tivoização , foi sugerido que há uma tendência acelerada e orientada pelo fornecedor para licenças mais permissivas . Como a vantagem percebida do FreeBSD para entidades comerciais reside em sua licença permissiva, há uma pressão crescente da base de usuários corporativos para se afastar do GCC e da GPL em geral.

Problemas com o GCC: Além da licença, o uso do GCC tem alguns problemas percebidos . GCC não é totalmente compatível com as normas, e tem muitas extensões não encontrados na norma ISO C padrão . Com mais de 3 milhões de linhas de código, também é " um dos projetos de software mais complexos e de código aberto / gratuito ". Essa complexidade torna a modificação do código no nível da distribuição uma tarefa desafiadora.

Vantagens técnicas: Clang tem algumas vantagens técnicas em comparação com o GCC . Mais notáveis ​​são as mensagens de erro muito mais informativas e uma API explicitamente projetada para IDEs, refatoração e ferramentas de análise de código-fonte. Embora o site Clang apresente gráficos indicando uma compilação e uso de memória muito mais eficientes, os resultados do mundo real são bastante variáveis e amplamente alinhados ao desempenho do GCC. Em geral, os binários produzidos pelo Clang são mais lentos que os binários equivalentes do GCC:

Embora o uso do LLVM seja mais rápido na criação de código que o GCC ... na maioria dos casos, os binários criados no GCC 4.5 tiveram um desempenho melhor que o LLVM-GCC ou Clang ... nos demais testes, o desempenho foi próximo ao do GCC ou bem atrás. Em alguns testes, o desempenho dos binários gerados pelo Clang foi simplesmente péssimo.

Conclusão: É altamente improvável que a eficiência da compilação seja um motivador significativo para correr o risco substancial de mover um grande projeto como o FreeBSD para uma cadeia de ferramentas do compilador totalmente nova, principalmente quando falta desempenho binário. No entanto, a situação não era realmente sustentável. Dada a escolha entre 1) executar um GCC desatualizado, 2) mudar para um GCC moderno e ser forçado a usar uma licença incompatível com os objetivos do projeto ou 3) mudar para um compilador licenciado por BSD estável, a decisão provavelmente era inevitável. Lembre-se de que isso se aplica apenas ao sistema base e ao suporte da distribuição; nada impede que um usuário instale e use um GCC moderno em sua própria caixa do FreeBSD.


4
A referência que você citou é de uma versão antiga do Clang. Os parâmetros de referência para as versões recentes parecem estar mais perto. Minha própria pesquisa para programas simples colocou o Clang 3.0 um pouco mais rápido que o GCC 4.6, mas o GCC foi 20% mais rápido na versão encadeada. phoronix.com/scan.php?page=news_item&px=MTA5Nzc é uma referência mais recente da Phoronix.
Sean

6
"O GCC não é totalmente compatível com os padrões": não é possível usar opções de compilador para impor a conformidade com um determinado padrão?
Giorgio

4
Antes de tudo, não leia muito sobre os benchmarks do Phoronix, ou melhor, não os leia. Segundo, é verdade que o GCC não é totalmente compatível com os padrões por padrão, a menos que você especifique explicitamente um padrão; caso contrário, as extensões GNU também serão ativadas, mas isso parece um motivo estranho para usar o Clang, pois eles também estão implementando as extensões GNU mais usadas porque se esforçam para que o Clang seja utilizável como uma substituição do GCC.
Kyrias

1
@Giorgio: Não. Veja um exemplo em gcc.gnu.org/c99status.html - e isso é apenas o C99 (que já tem 14 anos). Também gcc.gnu.org/onlinedocs/libstdc++/manual/status.html - o clang tem melhor suporte para ambos (acho que está cheio - e se não, definitivamente é pelo menos melhor).
Tim Čas 15/08/13

4
@ Demizey Não estou defendendo o Phoronix, mas se você vai descartar algo, deve pelo menos fornecer um motivo válido.
2026 Mario Mario

38

Uma coisa que vale a pena considerar é que o FreeBSD atualmente está usando o GCC 4.2.1, como observado na resposta ire_and_curses, portanto as comparações de desempenho não são de 4,5 ou mesmo 4,6 não são realmente relevantes para o projeto. Portanto, as perguntas que você deve fazer são:

  1. Quais são os ganhos de desempenho do novo Clang versus o GCC mais antigo que o projeto usa?

  2. Como os mesmos binários compilados no GCC 4.2.1 se comparam ao novo Clang?

Devido à mudança do GCC para a GPL v3, o FreeBSD foi forçado a continuar usando o GCC 4.2.1 (GPL v2), que foi lançado em 2007 e agora está significativamente desatualizado.

Se Clang fica atrás do atual CCG, mas ainda está anos-luz à frente do CCG implementado no projeto, sua decisão de evoluir é bem justificada e verdadeiramente inspirada.


19

Embora o GCC seja o GPLv3, os binários resultantes produzidos pelo GCC nunca tiveram nenhuma restrição de licença. É claro que você pode usar o GCC para criar software que se enquadre na licença que você deseja. Até a biblioteca C que acompanha o GCC e está incluída no binário é livre de licença. http://www.gnu.org/licenses/gcc-exception-faq.html

Seção 2 da GNU GPLv3:

Você tem permissão para propagar um trabalho do Target Code formado pela combinação da Biblioteca Runtime com Módulos Independentes, mesmo que essa propagação viole os termos da GPLv3, desde que todo o Target Code tenha sido gerado por Processos de Compilação Elegíveis. Você poderá transmitir essa combinação nos termos de sua escolha , consistente com o licenciamento dos Módulos Independentes.

"Elegível" significa que a compilação não envolve software incompatível com GCC e GPL. Isso não é uma restrição: o software licenciado pela BSD pode ser usado no processo de criação que envolve o GNU GCC.

Como você pode ver, ao contrário do que foi dito acima, não há motivo REAL relacionado à licença para se afastar do GCC, pois não há incompatibilidade com o uso do GCC no FreeBSD.

A verdadeira razão por trás dessa mudança é política e oportunista:

  • O BSD possui seu próprio licenciamento, que concorre filosoficamente com a licença pública GNU (como * ire_and_curses * explicado acima),
  • O CLANG é um novo compilador não-GPL iniciado por um patrocinador do FreeBSD que parece ser tecnicamente equivalente ao GCC licenciado pela GPL (como descrito acima por * ire_and_curses *).

Esses fatos criam uma oportunidade para o FreeBSD se afastar do GCC e se livrar dele: eles não são legalmente obrigados, pois ainda podem usar o GCC para criar software livre ou licenciado pelo BSD, mas querem seguir o exemplo filosofia de "todos os softwares licenciados pela BSD".


5
Desculpe, eu tive que votar isso. Infelizmente, a falta de familiaridade com BSDs e software é baixa. Só para constar, foi uma decisão política, não técnica, que levou os BSDs a mudarem de seu tradicional Portable C Compiler (PCC) para o GCC no início dos anos 90. Clang é o projeto da Apple! Como alguém que usa o GCC diariamente para viver no OpenBSD, que está tentando voltar ao PCC, você está errado em todas as contas.
Predrag Punosevac

5
Não é sobre os binários resultantes, é sobre o fato de o gcc fazer parte do FreeBSD - portanto, as restrições de licença são importantes.
sstn

3
Se a religião do projeto diz "No GPLv3", os aspectos técnicos desaparecem - imagine que eles estavam usando, por exemplo, um compilador da Microsoft.
Thorbjørn Ravn Andersen

3
Esta é a única resposta que aponta corretamente isso license of compiler != license of end product. As reclamações sobre uma licença do compilador não podem ser relevantes, a menos que o usuário não entenda a licença.
Brandin

6
Não se trata de saber se os binários produzidos se enquadram na GPLv3, mas se as alterações no próprio compilador exigem conformidade com a GPLv3. Os fornecedores de hardware geralmente modificam o compilador de estoque para trabalhar melhor com seu hardware ou tirar proveito do hardware de maneiras proprietárias. Remover o risco de que suas alterações personalizadas obedeçam à GPLv3 ou arriscar uma ação legal é um grande problema para essas organizações. É realmente a licença do compilador que importa aqui.
David harks

7

Não sou especialista, mas meu entendimento é que o Clang / LLVM usa menos recursos que o GCC e é mais rápido.

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

Se você está executando um ambiente em que precisa criar muitas coisas, muitas vezes, esse desempenho pode se transformar em economia real em custos e tempo de energia. Se é real.


Menor .. e não há ferramentas para reduzir tempos de compilação repetitivos ainda - ccache.samba.org Não importa as possibilidades óbvias para compilação parrallel (veja distcc), os tempos de ligação tendem a ser mais difíceis de resolver em grandes projetos
Rob11311

Sim, muito bom, mas o código binário resultante é mais lento; p
rustyx

1
@rustyx não comparado ao gcc 4.2!
Miles Rout
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.