Não é de hoje que eu falo da musl no meu canal e no meu blog. Uma das primeiras vezes que eu consigo me recordar de haver mencionado foi na série Muito além do GNU. Musl é a nova biblioteca padrão que dá mais poder a nova geração de dispositivos baseados em Linux tornando o sistema mais leve, mais rápido e mais seguro.
Caso ainda não conheça a biblioteca musl, fica aqui um vídeo para ter um resumo antes de continuarmos tratando do novo lançamento:
Não vou tratar dos seus novos recursos pois são mais mais mudanças internas como armazenamento de thread-local dinâmica, e trabalho em multi-threaded set*id(). São coisas que para mim que é da parte de administração do sistema é pouco uso (ou quase nenhum). Caso queira saber o que há de novo, aconselho a baixar a nova versão no site oficial que está logo abaixo:
Mas de qualquer forma, podemos agradecer a empresas e projetos como a Midipix e a Hurricane Labs e indivíduos como Neal Gompa, Les Aker, Laurent Bercot, Justin Cormack pela contribuição nesse novo lançamento.
Eu só gostaria de fazer as considerações do porque venho ao longo do tempo promovendo várias ferramentas que estão presentes no Linux e não são do projeto GNU. Muitos fazem até alvoroço dizendo que odeio GNU (mesmo que por várias vezes já disse que não, mas que também não me limito ao uso somente as ferramentas do projeto).
O que me chama a atenção na musl é o resultado final do tamanho de um binário tendo como dependência a biblioteca ao invés da glibc. A imagem abaixo ilustra isso comparando três distribuições:
Comparação do tamanho entre as imagens das distribuições CentOS, Ubuntu e Alpine.
É tal coisa que eu quero ver e se a musl apresentar melhor resultado do que a glibc, eu vou utilizar a musl. Mas se em outros aspectos a glibc apresenta melhor resultado do que a musl, eu vou então utilizar a glibc. É assim que nós agimos; nós técnicos e não filósofos de plantão.
musl é uma nova biblioteca padrão para dar poder à uma nova geração de dispositivos baseados em Linux. musl é leve, rápida, simples, livre e se esforça para ser correta no senso de padrões de conformidade e de segurança.
A musl segue o padrão POSIX 2008 base a risca e é possível ver durante o processo de compilação que é adotado fortemente o padrão ISO C99 na biblioteca e um número de interfaces não padronizadas para ter compatibilidade com funcionalidades entre Linux, BSD e a glibc:
musl está sob a licença permissiva MIT e possui suporte as arquiteturas x86 (32/64), ARM (32/64), MIPS (32/64), PowerPC (32/64), S390X, SuperH, Microblaze, OpenRISC.
Veja o vídeo da série Muito além do GNU para saber melhor sobre a Musl
Mas o que falta então para que musl se torna padrão nas distribuições Linux?
Assim como no LLVM/Clang (e é o que a comunidade LLVM mais reclama), é que faltam algumas extensões GNU extremamente importantes presentes somente no GCC e na GlibC e que não são documentadas pela comunidade GNU. Se vocês quiserem saber algo sobre essas extensões, é necessário entrar em contato com a comunidade GNU e perguntá-los sobre elas (e para eles responderem... aí já é outras história). Isso acaba dificultando que alavanquem e acaba amarrando projetos a ficarem dependendo das ferramentas que o GNU tem a oferecer (chega a ser estranho falar de liberdade...)
Faltam também um monte de localizações, dados, um monte de bloat do GNU (que acontece a mesma coisa), Name Service Switch, (NSS), serviços de rede, biblioteca (libnsl em específico) e 80+ CVEs. Quando esses recursos forem adicionados a musl, podem ter certeza, adeus glibc.
Apesar do que ainda falta para a sua melhor adoção (que estão trabalhando fortemente para ter por completo e que há longa data já é boa o suficiente para colocar em um ambiente de produção), a musl já apresenta suas viabilidades em comparação a glibc. Basta comparar o resultado final das duas:
Comparação de tamanho final de um binário entre musl e glibc.
Musl é uma biblioteca C para Linux que visa a substituição da tradicional GlibC trazendo muitos recursos que por anos não existem na glibc. Musl torna os programas mais enxutos, mais leves, mais estáveis, mais seguros e mais poderosos.
Existe casos de quando adotar ou não a musl. Aqui tem uma lista onde encontramos as diferenças funcionais entre musl e gilbc.
Musl é uma biblioteca C do Linux que visa a substituição da tradicional GlibC trazendo muitos recursos que por anos não existem na glibc. Musl torna os programas mais enxutos, mais leves, mais estáveis, mais seguros e mais poderosos.
Existe casos de quando adotar ou não a musl. Aqui tem uma lista onde encontramos as diferenças funcionais entre musl e gilbc.
A maioria das alterações nesta versões não são visíveis externamente, mas que trazem grandes mudanças para os desenvolvedores. Essa nova versão traz recurso de migração do time_t de 32 para 64-bits (necessário para corrigir a vulnerabilidade de 2038), muitas correções de bugs e adições das extensões GLOB_TILDE para glob, uma implementação non-stub da API de localização catgets, e a posix_spawn para chdir na child.
musl é uma implementação da biblioteca padrão C construída sobre a as chamadas de sistema da API do Linux, incluindo interfaces definidas no padrão da linguagem base, POSIX, e extensões amplamente aceitas. musl é leve, rápida, simples, gratuita e se esforça para ser correta no sentido de padrões de conformidade e segurança.
Hoje foi lançada a versão 1.2.1 da biblioteca musl e a principal parte foi a completa reescrita da implementação malloc trazendo forte hardening, avitar a fragmentação e a habilidade de retornar memória livre ao sistema em uma boa granularidade.
Essa versão também traz correções em regressos de arquiteturas de 32 bits, em algumas arquiteturas MIPS (incl 64-bit) e correção de alguns erros lógicos antigos no libc-internal lock para processos single-threaded.
Alpine Linux é uma distribuição segura, pequena e leve que faz uso da musl como biblioteca C no lugar da GlibC e do Busybox como terminal no lugar do Bash. Outras distribuições já passaram a adotar a musl como biblioteca C e há planos também por parte do Debian para a sua adoção (como já houve no passado).
Drew DeVault trabalha em adicionar melhor suporte a RISC-V na musl enquanto trabalha no port do Alpine Linux para a arquitetura baseado no patch abaixo:
Drew já escreveu três patches e integrou outro que foi encontrado no github ao seu port. Em contato com a equipe da musl, Ricth Felker solicitou a lista de contribuidores para conferir se não há omissões de nomes; o que foi lhe passado um dia depois. Vale acrescentar aqui que o toybox também receberá port para a arquitetura que é bem promissora.
Musl é uma biblioteca C para Linux que visa a substituição da tradicional glibc trazendo muitos recursos que por anos não existem na glibc. Musl torna os programas mais enxutos, mais leves, mais estáveis, mais seguros e mais poderosos.
Essa nova versão funde o port do RISC-V de 64 bits à implementações de nova biblioteca matemática de log, exp e pow. Também traz novas chamadas internas do sistema; correções de bugs nas chamadas de sistema das arquiteturas MIPS e Microblaze e vários (incluindo um potencial serio no layout TLS estático para bibliotecas compartilhadas em arquiteturas que utilizam "variante TLS I") e uma limpeza em vários comportamentos indesejáveis mas indiscutivelmente mandatórios pela especificação POSIX foram corrigidos como resultado das interpretações POSIX sendo renderizadas desnecessariamente.
musl já possui suporte a pelo menos quinze arquiteturas (sendo uma delas, RiscV) e vem sendo adotada cada vez mais pelas distribuições Linux. Há planos por exemplo de portar o Debian para a musl (no passado Debian já havia sido portado para outra biblioteca que, como se tratava de um fork da GlibC que fundiram os dois projetos, por esse motivo o Debian acabou retornando para a GlibC). Uma distribuição não fica atrelada a um único projeto tenda a liberdade de escolher outras ferramentas e até de se desvincular do que já tem.
Mas mesmo tendo suporte à varias arquiteturas, há um trabalho sendo feito para a biblioteca venha a ter suporte a arquitetura RiscV64 vindo de empresas como a Mforney, a cmpwn, a SiFive e até a Google.
Nesta versão a equipe removeu por hora o suporte a riscv32 (já que a ABI de 32 bits ainda não está estável) e portaram a distribuição Alpine Linux para riscv64 sem se depararem com problemas. Atualmente a comunidade Adélie Linux também está envolvida em um trabalho portando musl libc para arquitetura SPARC.
Aqui você pode assistir um vídeo do canal e conhecer um pouco mais sobre a história e características da biblioteca musl:
Foi lançada hoje a versão 1.1.21 da biblioteca musl. Para que não conhece, musl é uma nova biblioteca padrão para Linux fortemente focada na nova geração de dispositivos. Essa biblioteca torna Linux mais leve, mais rápida, mais simples de manter e foca no padrão correto de conformidade de padrão e de segurança.
Meu primeiro contato com essa biblioteca foi através da distribuição Alpine Linux. Depois disso já vi na Void Linux, na Adelie Linux, no Hermeric Linux, e já li a respeito de planos do Debian migrar para musl.
Esse novo lançamento trás melhorias no que diz respeito ao thread stack size, incluir um ganho no tamanho padrão de 80k para 128k, no default guard size de 4k para 8k, e permitir o padrão ser aumentado via ELF headers (desta forma, se os programas precisarem de pilhas maiores, eles podem ser construídos sem source-level changes, utilizando apenas o LDFLAGS).
Correção no MINSIGSTKSZ que gerava pilha insuficiente para o AIO threads no kernel, nos possíveis dealocks, o glb core foi reescrito para corrigir a inabilidade de verificar componentes de caminhos buscáveis mas não acessíveis a leitura (searchable-but-unreadable path components) e para evitar uso excessivo de pilha e syscalls desnecessárias.
Nesta nova versão novas funções foram adicionadas como reallocarray inspirada no OpenBSD (mais uma função inspirada no OpenBSD), suporte a temporizador de notificação SIGEV_THREAD_ID, tcgetwinsize/tcsetwinsize da futura POSIX e _Fork. também da futura POSIX (que traz vantagem de async-signal-safety).
A função realpath foi reescrita para não mais depender dos conteúdos do procfs magic symlink (fazendo funcionar em containers ou no chroot onde os conteúdos do /proc podiam não se tornar visíveis ao processo).
As versões C das funções square root, que são utilizadas em arquiteturas sem instruções FPU nativas, também foram reescritas com melhorias de desempenho (especialmente em arquiteturas que carecem inteiramente de FPU. Essa reescrita também corrige a falta de sqrtl necessária em arquiteturas com quad-precision long double.
Um bug buffer overflow (CVE-2020-28928) foi corrigido na função wcsnrtombs que também foi reescrita (função pouco utilizada e bug não muito relevante que não a utiliza diretamente por não ser utilizado por componentes de outra libc), mas que pode ser sério para software que a utiliza.
Muito além do GNU: Os vários sabores de bibliotecas C
Alguns dias atrás me deparei com o link do site osdev.org sobre implementações de biblioteca C; trata-se de um artigo bem interessante mas muito curto. Como eu já fiz vídeos e artigos relacionados ao tema para a minha série Muito além do GNU(lembrem-se que tudo no Linux é uma questão de escolha. Escolha diz mais respeito a liberdade do que uma ideologia ou uma simples licença), eu resolvi então explorar este texto fazendo minhas observações sobre cada uma delas acrescentando mais informação e adicionando outras.
As bibliotecas C mais populares são a glibc, uclibc, musl e dietlibc; mas há um mundo muito mais vasto e amplo do que você pode imaginar e aqui vou eu abordar muitas outras. No total, até o momento eu cataloguei por volta de 18 diferentes implementações de biblioteca C.
Eu não pretendo seguir na mesma ordem que está descrita no artigo e sim na minha própria ordem; basicamente, a ordem que eu conheci ou de forma que eu considero mais coerente de explicar.
De autoria de Roland McGrath e graças aos esforços de vários projetos e empresas que a mantem para que possam utilizá-la no Linux, é uma biblioteca absolutamente completa e possui suporte a quase todas as arquiteturas. Uma observação muito interessante feita no site:
"Ela não é escrita com nada além do Linux em mente, tornando-a um port difícil."
Sim, apesar de a glibc ser uma biblioteca do projeto GNU, tecnicamente a glibc é uma biblioteca do Linux. Isso ocorreu porque no inicio dos anos 90 os desenvolvedores de Linux perceberam que glibc carecia de muitos recursos necessários para Linux e assim eles criaram um fork da versão 1.x que foi nomeada simplesmente libc e que conhecemos como libc4 que foi a ultima com suporte ao padrão a.out, a libc5 (/lib/libc.so.5 a primeira a ter suporte ao padrão ELF no lugar do a.out. Há algumas fontes que afiram que havia código da bibliotecas C do 4.4BSD, mas o link do projeto gnu não está mais disponível) e libc6 (/lib/libc.so.6) e foram o padrão nas distribuições Linux durante um bom tempo. A glibc 2.0 surgiu da libc6 e com o tempo, por uma questão de padronização, as distribuições voltaram a utilizar a glibc. Mais informações da libc5 e libc6 podem ser lidos clicando aqui. Já para saber mais sobre libc4, libc5 e libc6 consulte a manpage (man 7 libc).
Houve também a Eglibc que foi uma variante da glibc fortemente focada em embarcados e com uma série opções e de suporte a arquiteturas que a glibc não possuía (especialmente PowerPC). A Eglibc foi a biblioteca padrão do Debian 5 e possuía suporte de um consorcio. O código da Eglibc foi fundido ao código da glibc na versão 2.20.
No final das contas a GlibC se beneficiou muito do Linux assim como quase todas as ferramentas do projeto GNU. É difícil prever a linha do tempo das ferramentas GNU sem o Linux.
Uma das grandes desvantagens da glibc podemos mencionar é o fato de gerar binários muito grandes. no artigo Analisando 6 diferentes implementações do comando sed eu descrevo uma curiosidade relatada por Rob Landley que, um simples código "hello World" linkado estaticamente à glibc, gera um binário de 400k... Não é a toa que os desenvolvedores de embarcados se declaram inimigos mortais da glibc.
E a outra desvantagem é estar sob a licença GPL que está em decadência desde 2007por ser uma licença muito restritiva (até hoje não entendo o conceito de liberdade em algo tão restritivo. Algo totalmente incoerente).A criação da GPLv3 foi uma corda no pescoço da licença e já houveram planos no passado para migra a glibc para a terceira versão. Ainda bem que isso não ocorreu pois geraria um grande colapso nos projetos.
uClibc (pronuncia-se yew-see-lib-see) é uma biblioteca para Linux em embarcados no projeto µClinux. Bem menor do que a glibc porém com suporte a quase todas as suas aplicações e quase todas as arquiteturas (alpha, amd64, ARM, Blackfin, cris, h8300, hppa, i386, i960, ia64, m68k, mips/mipsel, PowerPC, SH, SPARC e v850).
Foi escrita do zero por Erik Andersen, ex mantenedor do Busybox (que passou a bola para Rob Landley, autor do terminal de comandos toybox), iniciando em 1999 tendo apenas algumas partes de código derivados da glibc como pthreads (threads do Linux, o mesmo recurso que querem fazer uso dentro do sistema operacional RTOS X5) e o suporte a números randomicos.
O uClibc foi descontinuada por volta de 2012 e criaram um fork chamado uClibc-ng. Aé aonde se sabe, existem poucos mantenedores da uClibc-ng, ou talvez somente um, sob o argumento que é a única que possui suporte a algumas plataformas de hardware antigos.
Musl já apareceu várias vezes tanto aqui no blog quanto no canal. É construída sobre a API do Linux e a API POSIX e tem como princípios a simplicidade, eficiência de recursos, atenção em correções, segurança sob exaustão de recurso, fácil deploy e suporte de primeira classe para textos UTF-8/multilingual. A musl permite gerar binários menores (mesmo linkados estaticamente) e rápidos. Rich Felker criou o conceito Quality Safe Code; o que leva a biblioteca a ser correta no quesito conformidade e segurança.
Com o fim da uClibc e depois de ter péssima experiência com programas linkados a outras bibliotecas (seja de forma dinâmica ou estática) que apresentaram falhas, Rich Felker desenvolveu a musl como uma alternativa a glibc e a Uclibc para oferecer melhor experiência no uso de aplicações linkadas estaticamente (tanto no conceito de segurança quanto eficiência) em embarcados, servidores de desktops.
Inicialmente esteve sob a licença GPL porém, depois de conversa com Rob Landley (autor do toybox) passou a disponibilizar a musl sob a licença MIT. Hoje a musl é utilizada como padrão nas distribuições Alpine Linux que é inclusive utilizada nas imagens Docker; Adelie Linux que é baseada no Gentoo Linux e eu pretendo fazer um vídeo de Os vários Sabores de Linux; Void Linux que foi criada para implementar os gerenciador de pacotes xbps (haja coragem); Alpaquita Linux criada pela empresa Bell soft para a execução de aplicações Java; Glaucus Linux que, diferente da distribuição Alpine Linux, faz uso do toybox como userspace ao invés do busybox (tive a honra de receber seu autor no meu canal) e há planos para a sua adoção no Debian e no Android.
Possui em torno de 1200 funções além de todo um conjunto de funções matemática e de printf, porém ainda faltam system calls para serem implementadas. Natanael Copa, autor da distribuição Alpine Linux descreve em sua palestra o que é necessário para substituir a glibc pela musl. Foi a primeira biblioteca a adotar mutexes safe que o pessoal considera incrível, condvars e a primeira a ter working thread cancellation sem race conditions (todos recursos que foram ignorados por outras implementações).
De autoria do alemão Felix von Leitner, foi criada com foco em otimização de tamanho dos binários assim como a musl e cumpre muito bem esse papel. Eu mesmo já fiz analises tanto no canal quanto aqui no blog compilando o embutils, o minised e o init systemrunit e os resultados de sua otimização de binários são surpreendentes. Há um vídeo no meu canal onde relato a sua história e recursos interessantes.
skalibs é um pacote que centraliza bibliotecas C pequenas e seguras utilizadas para a construção de todos programas da skarnet.org. A ideia é não ter que baixar e compilar bibliotecas grandes e se preocupar com problemas de portabilidade. skalibs está sob a licença ISC e pode ser baixada através do comando
Newlib é uma biblioteca fortemente focada em embarcado. Alias, essa é uma das bibliotecas mais amada pelos desenvolvedores de embarcados. É utilizado até mesmo pelos amantes de Dreamcast (e eu não gosto, né). Ela conglomera várias partes de biblioteca sob licenças open-source. e em seu site oficial só é disponibilizada na forma de código fonte.
Possui suporte a mais ou menos 400 funções e requer threading. Nesse embalo surge a Relibc.
Relibc
relibc é uma biblioteca C POSIX escrita em Rust. De origem do sistema operacional redoxOS e possui port para Linux. Foi desenvolvida para ser uma alternativa a newlib (por isso coloquei nessa ordem) no RedoxOS e também possuir suporte a system calls do Linux (se system calls Linux tem muito bem) por meio do sc crate.
Bionic é a principal biblioteca do Android; foi construída com porões de bibliotecas do NetBSD, do OpenBSD, porções de bibliotecas de FreeBSD e partes próprias. Está sob a licença BSD para evitar os conflitos que vem ocorrendo com a GPL; existe até uma política do Android de não haver programas sob GPL no user space do Android.
Possui suporte a arquiteturas ARM e depois foi estendida a x86 além de suporte a interfaces do kernel Linux. existem algumas limitações como não possuir suporte a locales (até aonde me lembro, a musl também não possui quando tentei compilar o htop que descobri isso), a libthread_db ou libm e possui sua propria implementação pthreads baseada nos futexes do Linux. Existe um relato do Rob Landley que para poder executar o X11 no Android, seria necessário reescrever várias parte do X11 para ser compatível com a Bionic.
olibc (Another C Library optimized for Embedded Linux) derivada da bionic, o objetivo da olibc é fundir as melhorias feitas por várias empresas de SoC como a Qualcomm, Texas Instruments, Linaro, etc. A olibc pode se beneficiar de recursos do ARMv7 como NEON, Thumb-2, VFPv3/VFPv4 e as ultimas otimizações de recentes versões dos compiladores.
PDCLib (ou The Public Domain C Library) visa fornecer uma implementação completa do padrão C99 (nada mais, nada menos do que definido no ISO/IEC 9899. Nem mesmo outras extensões como POSIX) sob a licença CC0 ("No rights reserved").
Foi desenvolvida originalmente por Martin “Solar” Baute em 2002 e depois de 10 anos, Erin Shepherd assumiu o desenvolvimento até 2018 que implementou muitos recursos significativos (o currículo da Erin é incrível). Em 2018, Martin retornou ao desenvolvimento da PDClib.
Não confunda PDCLIB (The Public Domain C Library visto anteriormente) com a PDPCLIB (Public Domain Project C Library. Um P a mais e pode confundir dois projetos). Essa biblioteca faz parte do projeto PDOS (Public Domain Operating System) que se trata (digamos) de um clone antigo MSDOS. (mas com suporte tanto a 32 bits do Windows e do MSDOS. Há uma de suas distribuições com suporte a API MVS API em AMODE de 24, 31, 32 e 64 bit).
A PDPCLIB é biblioteca do PDOS que visa ser uma biblioteca C que visa junto ao GCCMVS (um port do GCC para mainframes da IBM) produzir binários sem restrições devido a sua licença (domínio público). A PDPCLIB segue os padrões da ISO/IEC 9899:1990 (aka ANSI X3.159-1989 aka C90 aka C89) e funciona não somente no MSDOS, no Win32 e no PDOS/386 mas também no OS/2, MVS (mainframe), CMS, VSE e AmigaOS.
Escrita em C++, mlibc tem como foco ser totalmente portável e na modularidade. mlibc possui uma variedade de recursos POSIX/Linux/ANSI e é capaz de executar vários programas como Weston, GCC, LLVM, Bash, GTK2/3 e muitos outros mas sem perder o foco na portabilidade (assumindo poucas systemcalls do sistema operacional hospedeiro). Está sob a licença MIT.
Como o próprio nome já menciona, é focada em ser escrita totalmente na implementação do padrão C11 (ISO/IEC 9899:2011) e nada mais. Está sob a licença unlicense (public domain), teve seu inicio em 2014 porém seu desenvolvimento anda bem parado. Seu antigo site (http://libc11.org/) está fora do ar, mas existem alguns repositórios git que podem ser encontrados.
Na computação, klibc é um subconjunto minimalista da biblioteca C padrão desenvolvida por H. Peter Anvin. Ele foi desenvolvido principalmente para ser usado durante o processo de inicialização do Linux e faz parte do espaço inicial do usuário, ou seja, componentes usados durante a inicialização do kernel, mas que não são executados no modo kernel.
Essa é uma biblioteca do kernel Linux. Foi adicionada ao kernel 5.0 no commit 66b6f755ad45como umabiblioteca mínima que fornece emulação de baixo nível quando o Linux for inicializado somente para executar um único e minúsculo programa.
Foi criado por Paul McKenney ao trabalhar para reduzir o tamanho do initrd (que é de 40MB) e do initramfs (que é 10MB) gerados pelo comando mkinitramfs e pelo dracut onde a maioria das coisas eram inúteis. Assim, eliminando o que não era necessário para o dash (e a maioria eram coisas relacionadas a biblioteca), Paul conseguiu reduzir para ~2MB.
Neatlibc foi desenvolvida pelo iraniano Ali Gholami Rudi para focar principalmente em bootstrapping de seu compilador neatcc. a neatlibc possui suporte as arquiteturas x86, x86_64, ARM de 32 bits; há muitas funções que não são implementadas na neatlibc mas a maioria dos programas desenvolvidos por Ali (http://litcave.rudi.ir/) podem ser compilados com o neatcc e linkados a neatlibc.
Escrita do zero para o sistema operacional Sortix OS, foi implementada grandes partes do padrão POSIX que permite ter suporte a ~70 partes de software de terceiros.
Libslack é uma pequena biblioteca de utilidades gerais que foi projetada com uma coleção de módulos e várias funcionalidades para torar a programação no UNIX/C um pouco mais fácil. A principio foi implementada para ser parte do programa daemon embora alguns códigos datam de antes do do daemon. A libslack possui vários recursos que podem ser conferidos clicando aqui. Está sob a licença GPLv3 e disponível para Linux, Solaris/OpenSolaris,OpenBSD, FreeBSD, NetBSD, MacOSX/macOS, kFreeBSD e GNU/Hurd.
MyOS libc
E por ultimo temos a myOS libc que resumidamente seria você mesmo desenvolver sua própria biblioteca C. A ideia é servir como uma das soluções mais óbvias implementando os recursos personalizados que precisa a seu kernel e ao resto do sistema operacional sem camadas de portabilidade. Outra parte interessante seria a melhor integração com funcionalidades do seu hardware.
O artigo não inclui o link para o desenvolvimento da biblioteca, então eu resolvi adicionar por conta própria.
