Aplicando o Clang Thread Safety Analysis ao kernel Linux
No Clang-Built Linux Workshop realizado Fevereiro deste ano, Lukas Bulwahn apresentou a ideia de aplicar o Clang Thread Safety Analysis ao kernel Linux. Já existem várias soluções (inclusive utilizadas pelo Linux) para realizar tal tarefa como sparse, smatch, coccinelle (mini_lock.cocci rule), lockdep, KCSAN, coverity e até ferramentas não open source para tal propósito. Porém, o CTSA trás características diferentes.
Clang Thread Safety Analysis é uma extensão do Clang escrita em C++ (funciona também para a linguagem C) que foi desenvolvido pelo Google e pela CERT/SEI. Clang Thread Safety Analysis emite avisos de potenciais condições de race (potential race conditions) no código fonte, possui fácil configuração, é rapidamente executado, adequado até mesmo para estudantes;
Porém, não entrega os resultados mais promissores (algo que vem sendo trabalhado para melhorar). Agora é aguardar para ver no futuro.
OpenMandriva passa a distribuir kernel compilado com o clang
Em 2014, a comunidade OpenMandriva migrou do gcc para o LLVM/clang. Hoje, quase todos os pacotes do OpenMandriva é compilado com o LLVM/clang (menos a glibc, elfutils e outros pacotes que não são clang friendly). Depois disso outras distribuições como Debian, Android e Fedora passaram a adotá-lo no mesmo estilo (100% do Android é compilado com o LLVM).
O LLVM possui suporte as arquiteturas i686, x86_64, znver1, armv7hnl, aarch64 e riscv64. Exits suporte a toolchain cross compile para todas as arquiteturas mencionadas e o openMandriva fornece um automatic build farm chamado ABF gerando pacotes RPM e imagens ISO baseado no código fonte do projeto ou até mesmo no seu próprio. O ABF também possui uma CLI chamada abf-console-client permitindo trabalhar direto nos pacotes do projetos (você pode até mesmo doar ciclos de CPU).
Nick Desaulniers informou que a comunidade OpenMandriva passou a disponibilizar o kernel Linux compilado com o clang que recebeu o nome de kernel-release-clang e incentiva aos usuários a comparar o kernel atual com essa versão.
Galera, estes artigo é somente um aviso rápido. Já divulguei o lançamento do compilador LLVM/Clang quando foi a versão 4.0.1, a versão 5.0, a versão 5.1 e agora que divulgar que está disponível a versão 6.0 do compilador LLVM disponível para download que foi um trabalho árduo de seis meses. Esse lançamento trás vária melhorias que podem ser conferidas nas notas de lançamento.
O dia em que o pinguim adquire asas e cauda de um dragão de ferro.
Desde que eu utilizo Linux, os asciduos usuários de Linux sempre utilizaram o argumento de Linux é somente o kernel enquanto que as ferramentas são do projeto GNU. Este argumento, além de fraco e inutil, deixa as pessoas confusas quanto ao Linux, desvirtua as pessoas do verdadeiro conhecimento tecnico e afasta-as de conhecer novas ferramentas que poderia ser muito mais uteis. Existem Muitas ferramentas que podem substituir as do projeto GNU tanto em empresas quanto no uso comum em seu dia a dia. conheça aqui algumas delas.
Anos atrás (especificamente em 2010) li a noticia de ser possível compilar o Linux com o Clang. Eu, com a minha paixão pelos ideais de software era grande, discordei de tudo o que foi dito (paixão é fogo e nos cega). Alguns dias (ou semanas) depois, publicaram um benchmark entre algumas versões do GCC, do Clang, do ICC da Intel e do ovo de dragão (Dragon Egg).Passado algum tempo, tive a curiosidade de pesquisar sobre o Clang e acabei gostando do que descobri a respeito do compilador. Foi bom saber que haviam outras opções para compilar o Linux além do GCC; como em tudo o que há no Linux são outras opções (GUIs, editores de texto, navegadores, terminais de comando, comandos e tudo mais, a regra vale também para compiladores, bibliotecas e tudo mais).
Esse é o tipo de liberdade que gosto; a liberdade de escolher o que quero e o que vou utilizar; a liberdade se estende a muito mais do que as citadas pela GPL e não ficar preso ou limitado à uma única opção. Seria a mesma liberdade que tenho de ir ao mercado e poder escolher se quero presunto de uma marca ou de outra (a lei da concorrência existe para isso, assegurar o nosso direito como consumidor e desta forma, as empresas busquem conquistar seus clientes com a melhoria continua de seus produtos ou serviços).
Como mencionei, eu até era extremo defensor de software livre e de código aberto (ainda defendo a adoção de ferramentas open source, mas não da forma que eu abordava anteriormente acreditando que software proprietário representam ameaças à humanidade), recebia newsletters da FSF por e-mail, porém, tomei antipatia quando Richard Stallman ficou cantando vitória sobre a morte de Steve Jobs. Mas ainda assim, continuei com os ideais de software livre e de código aberto. Certa vez participei de um podcast onde um dos convidados que não vou mencionar o nome (e por favor, não me perguntem quem é, pois não irei responder; citação de nome é difamação) era defensor de software livre. Até aí tudo bem, eu também era; o problema é que o cara não queria participar simplesmente pelo fato do software que iria ser utilizado para gravar não era (totalmente) livre; isso rendeu alguns comentários. Depois começou a ficar difícil interagir com ele, pois tudo para ele era somente software livre sem ouvir o que o outro lado tinha a dizer. Percebi que eles pregam a liberdade mas se tornam escravos de tais ideais, se tornam flexíveis.
Gosto de software livre e de código aberto, não deixei de usar as ferramentas do projeto GNU (e talvez não deixa de usar tão cedo), mas da comunidade eu passo longe (a não ser que venham me encher a paciência kkkk).
Alguns dias atrás, um amigo conversou comigo sobre chamar o sistema de GNU/Linux ou simplesmente de GNU, e não somente de Linux (como assim?). Beleza; o assunto encerrado depois de longo debate entre nós. Coincidência ou não, um ou dois dias depois um seguidor do meu canal comentou a mesma coisa no meu vídeo "Linux (dando nome a criança):
O nome correto é Linux e não de GNU/Linux (e muito menos somente de GNU. GNU seria horrível). Primeiro porque Linux é um nome proprietário (uma propriedade intelectual de Lius Torvalds que pode lhe autorizar utilzar seu nome ou não); segundo, não há somente ferramentas GNU presentes no sistema operacional Linux (isso sim é uma verdadeira falácia e desinformação); terceiro, as ferramentas GNU são substituíveis e quarto, ambos são projetos distintos com propósito e propostas diferentes. Essa guerra por reconhecimento de nome do sistema operacional é na verdade relacionada a ego e não ao argumento meritocracia. Mesmo que discordem de mim, eu afirmo:
O GNU só é um projeto bem sucedido e amplamente utilizado graças a sua adoção pelo Linux (mesmo o GNU sendo mais velho). Duvido que o Gnu seria amplamente conhecido se não fosse o Linux.
Se considerarmos chama-lo de GNU/linux ou somente de GNU, então deveríamos considerar todos os outros projetos que utilizamos no Linux e que não fazem parte do GNU e que compoem o sistema operacional.
Quando se fala de GNU, as pessoas só lembram do stallman; não nos lembramos de pessoas como Brian fox que foi o autor do Bash, do GNU Makeinfo, do GNU Info, do GNU Finger, thereadline e history libraries além de ter sido o mantenedor do GNU Emacs por um tempo (e há quem acredite que o Stallman que é o cara). Alias, em torno de 80% das pessoas nem sabem destas coisas e acabam dando créditos ao Stallman.
Brian Fox, autor do GNU Bash
Muitos não se lembram de Mark Adler, que foi um os criadores do Gzip (e que inclusive é um dos responsáveis pela missão espacial para Marte).
Mark Adler, um dos autores do Gzip e um dos responsáveis pela missão de exploração ao planeta Marte.
Muitos não se lembram de pessoas valiosas como essa. Já quando falamos de linux, o caso é o contrario disso; quem já esteve em um evento como a Linuxcon sabe que isso é bem diferente.
Existem muitas ferramentas do GNU que são utilizadas no Linux, e disso todos nós já sabemos. Ferramentas como: GCC, make, Glibc, Bash, Coreutils, Emacs, Gzip e etc. A questão é que tais ferramentas são passíveis de substitução; é aí aonde a liberdade entra em cena.
Então, para esclarecer esse assunto, selecionei aqui algumas dentre as muitas ferramentas que são possíveis utilizar no lugar das mencionadas do GNU. Não estou fazendo isso com a intenção de discussão, apenas procurando ajudar vocês a ampliarem seus conhecimentos e abrir os seus olhos para a gama de software de qualidade que o mundo proporciona.
LLVM (Low Level Virtual Machine) é uma coleção de compiladores modulares e reutilizáveis que foi iniciado como um projeto de pesquisa na universidade de Illinois. Está sob licença open Source UIUC no estilo BSD. que mencionam que pretendem mantê-lo permanentemente aberto.O Clang, compilador que mencionei no inicio deste artigo, que é uma alternativa ao GCC, faz parte do LLVM. A palavra Clang (pronuncia-se cléng) é uma onomatopeia em inglês do som emitido pelo metal. O Clang possui as características de compilação mais rápida, menor uso de memória e melhores ferramentas de diagnósticos como no modelo apresentado abaixo:
Comparação das ferramentas de analise de log do GCC e do Clang.
Há muitos recursos e atributos interessantes no LLVM/Clang para os desenvolvedores e pessoas que integram sistema podem tirar vantagem quando desenvolver ou implantar seus próprios projetos. Um outro recurso interessante mencionado no site do Funtoo Linux, é a sua capacidade de compilação de programas Leiam o artigo em http://www.funtoo.org/Clang ou leia na imagem abaixo:
Existem muitas empresas trabalhando e investindo recursos nesse projeto. Até mesmo a Microsoft está investido recursos financeiros no LLVM, pois irá basear o seu futuro .Net no LLVM.
Acompanhe a lista de empresas e projetos que utilizam o LLVM
Na verdade, até aonde se sabe, existem quatro compiladores que são capazes de construir o kernel Linux sendo eles o GCC (que na verdade é o EGSC), o TinyCC do criador do ffmpeg, o ICC da Intel e o LLVM/Clang. Nos vídeos abaixo você pode conhecer melhor sobre os compiladores.
Musl (pronuncia-se mâssl) uma biblioteca C desenvolvida do zero. O site do Musl mostra um gráfico comparativo entre as bibliotecas C. A empresa OpenWall faz referência a biblioteca Musl por oferecer suporte nativo ao pacote TCB.
Existe a distribuição Alpine Linux que faz uso dessa biblioteca ao invés da Glibc e do Busybox ao invés do Bash. Para quem não sabe o que é o Busybox, ele é conhecido como o canivete Suíço do Linux embarcado. É um conjunto de comandos dentro de um único executável. É o Busybox que fica dentro o initrd para o kernel utilizar no momento do boot. Foi originalmente desenvolvido por Bruce Perens que já foi presidente do projeto Debian assumindo o lugar de Ian Murdock.
Aproveitando que falamos de terminais de comandos, existem também pacotes com comandos complementares como no caso o CoreUtils do GNU que, semelhantes a esse são o embutils criado por Felix von Leitner (criador da dietlibc que eu acho incrível); o 9base de origem do plan9 e portado para outros sistemas operacionais; o sbase que é uma coleção de comandos herdados dos Unix e portados para 5 Unix diferentes e o ubase que já é específico para Linux seguindo mesmo espirito do Util-Linux e está sob licença MIT e X; o ubase pode ser compilado com o GCC, LLVM ou TCC e é altamente recomendado compilar com a musl.
Até mesmo os comandos do toybox que podem ser compilados separadamente. Porém, estes pacotes não fornecem apenas um conjunto básico de comandos não sendo o suficiente para ter um sistema operacional em funcionamento. Como exemplo, o coreutils não fornece comandos para formatar partições, configurar rede, gerenciar processos, drivers, serviços e muito mais (o argumento apresentado para tentar chamar o Linux de GNU/Linux é simplesmente muito superficial e utilizado pela equipe do GNU e da FSF para se promover). Estes comandos são fornecidos por outros pacotes sendo muitos deles do próprio Linux e alguns deles criados pelo próprio Linus Torvalds e outros com sua participação:
Tukaani, era uma distribuição derivada do Slackware (que merecia ter sido mencionada no meu vídeo sobre o Slackware devido a sua ótima contribuição) e que deu origem a alguns projetos. A distribuição não existe mais, mas as ferramentas que eram parte integrante da distribuição estão em pleno desenvolvimento.
Em suas primeiras versões chamava-se de LZMA, é um compressor que nasceu na distribuição. O XZ hoje é utilizado fortemente pelo kernel desde de Dezembro de 2.013 e pelo Funtoo desde 2.008 (como mencionei no meu artigo parabenizando a equipe do Funtoo). O XZ apresenta melhor compressão do que o Gzip mesmo em compressões com o Gzip utilizando a opção "-9". Na verdade o XZ apresenta melhor compressão até mesmo que o Bzip2.
Dentre os casos de sucesso do CMake podemos ver o Netflix, o KDE, o game Second Life, sistemas de robóticas, o MySQL entre outros. Um coisa que considero a equipe do CMake é a sua humildade.
Falando de CMake, eu não poderia deixar de citar o Scons, que também é uma ferramenta de construção. Escrita em Python, o Scons visa ser um substituto para o tradicional make e que possui funcionalidade integrada semelhando ao autoconf/automake.
Muitos já elogiaram o Scons; pessoas como Eric S. Raymond, authr de "A Catedral e o Bazaar", Timothee Besset da id Softwareonde menciona que o Linux build system do Doom3 utiliza o Scons e que é show. Essa já é a segunda vez que ouço que o Scons é utilizado em compilação de alguma coisa relacionada a jogos. Gosto de considerar a parte da avaliação envolvendo jogos devido sua dificuldade de programação que envolve inteligencia artificial, simulação de física, renderização e etc.
O mk surgiu no sistema operacional Plan9 como um simples substituto para o make, mas que provê várias extensões, flexível e execução em paralelo. É possível compilar o mk também para Linux, BSDs (Free/Net/OpenBSD e Darwin), Solaris, HP UX e OSF1.
Smake é focado em alta portabilidade já que GNU Make não está disponível para todas as plataforma que o Smake (Linux, Windows (até MSDOS), MacOSX (e versões anteriores), Solaris, SSPM, PPC, HPUX, AIX), gnu make não permite realizar debugging no Makefile.
O comando smake e suas opções de des/compactação.
O Smake possui também seu Makefiles que permitem montar uma source tree via NFS e simultaneamente compilar (e reutilizar) para todas as plataformas. Além do Cmake, do Scon, do MK e do Smake temos também o Ninja Buil e o Samurai é compatível com o Ninja Build (e até mesmo um concorrente direto).
Exemplo de uso do smake
Ninja Build, Samurais e Meson Build System
Ninja Build foi criado por um desenvolvedor do Google o Google Chrome mas hoje é utilizado para construir partes do Android, do LLVM e pode ser utilizado em muitos projetos devido ao backend Ninja do CMake.
O samurai é uma ferramenta de build compatível com o ninja escrito em C99 com foco em simplicidade, velocidade e portabilidade. O Meson® é um projeto que visa criar a melhor proxima geração de build system.
Man
Apesar de muito conhecido, incluí o Man nessa história por que o GNU possui o seu próprio, o comando info. Detesto o info; hora ele é útil, a maior parte do tempo não.
É um framework muito conhecido por ser utilizado no desenvolver o KDE a interface do Netflix, do Android e muito mais. Menciono essa pois acho mais poderosa do que a GTK (apesar que nem o GTK, o Gim e nem o GNOME são projetos do GNU mesmo eles proclamando que são).
Existem muitos outros projetos que são possíveis substituir os do GNU como:
Shells:Tcsh, Zsh, o rc do Plan9 (que nessa brincadeira, podemos mencionar também o es), o elvsih que é um shell escrito na linguagem Go, o BusyBox que é utilizado pela distribuição Alpine Linux ao invés do Bash.
Coreutils pode ser substituído pelos já mencionados o BusyBox (que alias, são mais utilizados que o Coreutils), o embutils, o 9base portado do sistema operaciona Plan9, o sbase do Unix original portado para outros unix que nesta lista inclui Linux. Vou incluir aqui o Uitil-Linux e o ubase pois, algo que os usuários de Linux precisam (e devem) saber é que, ao contrários do que todos imaginam, o Coreutils não fornece todos os comandos que utilizamos no sistema operacional, apenas uma pequena fatia deles, os comandos basicos para o usuário. Já os comandos para administrações do sistema operacional são fornecidos por outros pacotes.
É perceptível que projetos fora do GNU ou até forks são em certos aspectos mais eficientes em seus propósitos. Não estou aqui difamando o projeto GNU, mas a mesma mensagem que deixo aos usuários de Windows envio também às comunidades de software livre de código aberto: Não devemos ficar presos unicamente à ideias ou paixões. O mundo é muito mais amplo do que possamos imaginar e podemos usufruir de tudo isso dando chance a outros projetos também. Adaptar ou morrer é um fato.
Se uma ferramenta surge para bem e vindo a substituir a já existente, ela deve ser bem recebida. Isso é algo que acontece constantemente no Linux. Essas ferramentas vem para a melhoria das nossas próprias vidas. O que vejo é muita rivalidade inútil ao invés de foco na coisa mais importante, que é a melhoria contínua.
Lembrem-se não somente do GNU, e sim de todos os projetos de open source que compoem o Linux (está muito longe de ter somente ferramentas do GNU presentes no sistema operacional). Lembrem-se de todas as licenças que também proporcionam e possibilitam a liberdade (GPL não é única. Existem em torno de 800 licenças). Lembrem-se de todas as pessoas que contribuem para esses projetos; graças a elas é que os projetos tem crescido e evoluído. E o mais importante unindo aos três itens mencionados, lembrem-se de serem livres (liberdade vai além da GPL, FSF e GNU).
Existe até mesmo o projeto da LLVM Linux Foundation que visa compilar totalmente o kernel utilizando o Clang (fronend do LLVM). Algumas distribuições, projetos e empresas já migraram para o compilador como a própria Apple (forte a adotar o LLVM), o Open Mandriva ja compilou 94% dos seus pacotes com Clang, o Android é 100% compilado com o LLVM, o Debian hoje compila grande parte dos seus pacotes usando o LLVM/Clang, é fortemente indicado para embarcados, FreeBSD, PCBSD, Sony, Qualcomm e mais uma lista gigantesca de empresas.
Antes de finalizar o ano, o projeto LLVM/Clang lançou a versão 9.0.1. Essa é uma versão de correção de bugs da versão anterior e mantendo sua compatibilidade. Não há muito o que se falar, mas eu não queria deixar passar batido o seu lançamento (e o seu próximo lançamento está previsto para 6 ou 7 de April de 2020). Fica aqui também um forte agradecimento aos financiadores do projeto que tem permitido esse compilador acontecer.
Nesse feriado aqui no Brasil de 7 de Setembro foi lançada a nova versão do compilador saltando de 4.0.1 para 5.0 já que na nova versão possui um novo esquema versão (assim como aconteceu no Linux).
Nessa nova versão que foi um esforço de seis meses para o lançamento, foi adicionado suporte a C++17, co-rotinas, melhorias no desempenho, no warinig no compilador, muitas correções de bugs e muito mais.
todas as informações estão nas notas de lançamento que podem ser conferidas logo abaixo:
Quando o assunto é desempenho, Linux é o melhor sistema operacional. E antes que surjam fanboys me chamando de fanboy, Linux se torna a base de referencia quando algum projeto ou empresa quer ou precisa analisar o real desempenho de outros sistemas operacionais. No History do site de DragonflyBSD é descrito que de uma perspectiva de desempenho, o único competidor real do DragonflyBSD é o Linux. Já no meu artigo 3 sistemas operacionais que não são escritos na linguagem C, o sistema operacional JX que é desenvolvido em Java, analisou o seu desempenho tendo Linux como comparativo. Brendan Gregg, um dos mestres na arte de performance e que escreveu algoritmos que melhoraram o desempenho do Solaris, descreve que, out of the box, Linux é mais rápido.
Comparando o desempenho do JX vs Linux
AQUI VAI UMA CONSIDERAÇÃO MUITO IMPORTANTE
A análise relacionada a performance é algo que oscila muito. Brendan Gregg mesmo ressalva que o desempenho de um sistema operacional depende do workload e que essas diferenças podem oscilar entre 5% á 5 vezes mais. Através de análises e configurações, Brendan conseguiu colocar o SmartOS (fork do Solaris) para ter melhor desempenho que o Linux e conseguiu também o mesmo feito ao contrário.
Em uma análise de jogos por exemplo, por várias vezes no passado eu mencionei que, mesmo que o Windows não possuísse o desempenho e qualidade tão bom quanto a do Linux, seu desempenho em jogos era muito melhor devido o emprego do DirectX. Eu ainda mantenho essa mesma afirmação se compararmos DirectX vs OpenGL. Porém, com o surgimento do Vulkan, esse quadro tem mudado bastante; a diferença de desempenho entre Windows+DirectX vs Linux+vulkan é bem baixa em favor do Windows e depois do surgimento do DXVK (DiretcX to Vulkan) que favorece muito os usuários de Linux rodar jogos do Windows sem a necessidade de ports, muitos dos desenvolvedores já mostraram que é possível rodar os jogos do Windows no Linux com o desempenho bem melhor do que no próprio Windows.
Esclarecido os detalhes sobre desempenho, agora vamos a o que importa neste artigo. No dia 21 de Junho foi publicado uma série de patches que irão melhorar ainda mais o desempenho do kernel Linux. Esses patches fazem exploram o recurso CC_OPTIMIZE_FOR_PERFORMANCE_O3, ou simplesmente -O3. O -O3 vai estar desntro do arquivo Kconfig ou podendo compilar o kernel Linux com a opção make KCFLAGS=-O3.
Não necessariamente se trata de um novo recurso, as opções de otimização já estão presentes nos compiladores GCC e LLVM/Clang há algum tempo. Como pode ser conferido nas imagens abaixo, eu já o utilizo na compilação do bc do Gavin Howard; pode ser conferido no GCC digitanto gcc --help=optimizers e na manpage do LLVM/Clang (man 1 clang em Code Generation Options)
Configuração do bc com a opção -O3
gcc --help=optimizers
otimização do código com o clang -O e a opção desejada
O kernel Linux já utiliza tal recurso, porém a opção -O2 por padrão e no meu artigo Redução do kernel Linux e do filesystem para IoT é apresentado a opção -Os para a otimização de tamanho (optimize for size, uma das opções que podemos escolher). O LLVM ainda apresenta a opção -O4 que é bem parecido com o -O3 e nas duas imagens abaixo eu mostro que compilei o bc com esta opção.
Configurando o bc de Gavin Howard com a opção -O4
-O4 durante o processo de compilação do bc
Por volta de 2019, já haviam tentado implementar a otimização -O3 no kernel Linux, mas havia sido rejeitado por Linus Torvalds devido o código que havia sido enviado não ser confiável o suficiente. Hoje, depois de passarem por revisão e melhorias, tais patches começam a ser aceitos e apesar de ainda estarem em estágio beta, o site Phoronix realizou um benchmark que mostram serem promissores.Vamos torcer
CONCLUSÃO
É possível melhorar ainda mais o desempenho em todo o sistema operacional Linux, e não somente em seu kernel. Particularmente, eu tenho uma ideia do desenvolvimento de uma distribuição que tem como um dos princípios melhorar ainda o desempenho de todo o sistema operacional (não com o mesmo argumento de muitas distribuições surgem "essa é uma distribuição estável, segura e com alto desempenho" mas que na prática não oferece nada demais). Essa não seria sua unica característica, mas um de seus princípios. Quem sabe no futuro? Pode ser que até lá alguém já faça isso no meu lugar, pessoas podem acabar tendo a mesma ideia mesmo não sendo expressadas. Se até lá alguém fizer me poupará muito tempo.
![pode ocorrer de alguns programas não compilarem (como o glibc) por que eles dependem de extensões específicas do GCC (é por isso que todo o código do BSD pode ser compilado com o LLVM mas alguns códigos GNU não) [nota do redator: liberdade?] ou padrões depois de compilação com sucesso do LLVM (como o xorg-server) ... ... Os frontends do C/C++ do LLVM, clang and clang++ na versão 3.0 são estáveis o suficiente para ser self-hosting compilar Boost, Qt, LibreOffice, FreeBSD, algumas partes do kernel Linux kernel e muito mais.](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjZJtSczVFcSlqpweUVyGsybNhVjUK8NLeDhecPkxgPZI3yAibw1HvAjxOvtISw2d-g99Yd60GZGEk1Z5soDl9dtxXXYc5RDmw0ZVI-UfEFGzFVa3o8Xu0NbB5JjSFtRXiRhXy6pKJZ_qA/s1600/clangOnFuntooLinuxDocumentation.png "pode ocorrer de alguns programas não compilarem (como o glibc) por que eles dependem de extensões específicas do GCC (é por isso que todo o código do BSD pode ser compilado com o LLVM mas alguns códigos GNU não) [nota do redator: liberdade?] ou padrões depois de compilação com sucesso do LLVM (como o xorg-server) ... ... Os frontends do C/C++ do LLVM, clang and clang++ na versão 3.0 são estáveis o suficiente para ser self-hosting compilar Boost, Qt, LibreOffice, FreeBSD, algumas partes do kernel Linux kernel e muito mais.")
