EGLIBC: uma distribuição da glibc (e não um fork)

A glibc (GNU C library, ou biblioteca C do GNU) é um componente fundamental do Linux. Ela provê boa parte da interface do espaço de usuário ao kernel, além de uma boa parte das rotinas utilitárias usadas por praticamente todos os aplicativos do Linux. Uma variante da glibc, a EGLIBC (Embedded glibc, ou glibc embarcada), não é muito conhecida fora do círculo dos dispositivos embarcados, mas parece que isso vai mudar com o anúncio de que o Debian vai mudar da glibc para a EGLIBC.

O projeto corre a esclarecer que não se trata de um fork da glibc, já que o objetivo é manter a compatibilidade (binária e de fontes). Em vez disso, a EGLIBC é como uma distribuição da glibc, incluindo patches para resolver problemas e facilitando o uso de aplicativos embarcados. Ela também oferece suporte a arquiteturas embarcadas que não são o foco de desenvolvimento principal da glibc.

O projeto, iniciado em 2006, é liderado pela CodeSourcery, que oferece compiladores e outras ferramentas de desenvolvimento baseadas no GCC para seus clientes. O chefe da CodeSourcery, Mark Mitchell, diz que ela fornecerá apoio administrativo ao projeto e “liderança, mas não controle”. Seu clientes são distribuidores de Linux embarcado e fabricantes de hardware, e a EGLIBC surgiu da busca deles por soluções menores de bibliotecas em C.

Mitchell disse que esses clientes estavam de olho na uClibc como alternativa à glibc, mas que o uso da uClibc tem algumas desvantagens, já que “dá muito trabalho fazer com que aplicativos que funcionam com a glibc funcionem com a uClibc”. Por causa do uso universal da glibc, “o Linux que você roda em um supercomputador e o Linux que você roda no telefone celular são muito parecidos.” Uma das principais vantagens da uClibc, no entanto, é sua capacidade de personalização, que possibilita aos desenvolvedores de embarcados desativar recursos que não sejam necessários para seus produtos – o exemplo clássico citado por Mitchell é o NIS.

Isso levou à adoção de “grupos de opções” na EGLIBC, que podem ser ativados e desativados de maneira mais ou menos independente para reduzir o tamanho da biblioteca. Há aproximadamente 30 grupos de opções definidos atualmente, mas o projeto espera que os novos contribuidores incluam outros grupos. Usando os grupos de opções, é possível desativar coisas como a rede (ou apenas a rede IPv6), bibliotecas matemáticas, o RPC da Sun, streams (ou “fluxos”), várias opções de internacionalização e localização e mais.

Trabalhar com o mantenedor da glibc, Ulrich Drepper, pode ser difícil devido, ao menos em parte, aos seus modos rudes. Embora Mitchell não tente comparar a comunidade de desenvolvimento da EGLIBC à do glibc, parece que a EGLIBC está tentando ser um upstream mais receptivo. Outros, incluindo Aurélien Jarno, do Debian, que anunciou a mudança para a EGLIBC, são menos reticentes, e apontam a dificuldade de se trabalhar com Drepper como a principal vantagem da EGLIBC.

De sua parte, Mitchell gostaria de ver uma “comunidade vibrante de código aberto” se formar ao redor da EGLIBC, observando que “quem vier será bem-vindo”. Embora o projeto seja financiado por um consórcio de empresas (Freescale Semiconductor, MIPS Technologies, MontaVista e Wind River), não é preciso trabalhar nessas empresas para contribuir. Os patches também não precisam ater-se ao dispositivos embarcados; correções de bugs e recursos não aceitos pela glibc serão considerados. Mitchell disse que a EGLIBC espera contar com contribuições de qualquer pessoa, e diz estar particularmente “esperançoso de que o Debian contribua” com o projeto.

Para que qualquer contribuição possa ser passada para a glibc, a EGLIBC exige que os contribuidores atribuam os direitos autorais à Free Software Foundation como em um patch para a glibc. A ideia é a de que o código da EGLIBC não se afaste demais da glibc; na verdade, as alterações na glibc são frequentemente incorporadas à EGLIBC. O desenvolvimento principal da glibc é “focado em x86 e em hardware para servidores”, explica Mitchell, mas se isso mudar, a EGLIBC pode ser fundida ao projeto upstream. “Nós ficaríamos felizes se a glibc da FSF pegasse tudo o que fizéssemos, ao ponto da EGLIBC não ser mais necessária”, diz ele.

Jarno mostra-se claramente frustrado com a forma como se dá o desenvolvimento da glibc, citando a declaração de missão da EGLIBC como parte do anúncio: “Encorajar a cooperação, a comunicação, a civilidade e o respeito entre os desenvolvedores.” Mas essa não é a única vantagem da EGLIBC, e ele lista várias outras, incluindo a capacidade de configuração, uma suíte de testes melhorada e um melhor gerenciamento da árvore estável que disponibiliza correções de bugs importantes para versões anteriores.

Em um post na lista debian-devel, Jarno lista mais alguns motivos, bem como respostas para algumas das perguntas que foram feitas a ele. Para o Debian, em especial, o suporte a muitas arquiteturas diferentes, incluindo diversas arquiteturas embarcadas, é muito importante. Ele destaca que a EGLIBC é uma substituta essencial à glibc para que os objetivos de compatibilidade do projeto sejam mantidos. As solicitações comuns para que sejam adicionadas as funções de manipulação de strings strlcat() e strlcpy() do BSD para evitar buffer overruns provavelmente não serão atendidas justamente por causa da compatibilidade.

A EGLIBC claramente oferece coisas que a glibc comum não oferece, e não apenas para desenvolvedores de embarcados. O foco na capacidade de inclusão provavelmente expandirá o grupo de hackers de bibliotecas em C, coisa que a comunidade de desenvolvimento atual do glibc não encoraja ativamente. Com sorte, a EGLIBC também atuará como um laboratório para correções e recursos, especialmente ao conseguir mais destaque e mais testes graças ao Debian, o que pode levar a uma glibc melhor no futuro. Vai ser interessante ver se outras distribuições vão dar o mesmo passo que o Debian deu, e o que isso pode significar para a glibc no futuro.