Kernel tem API baseada em interrupções e números mágicos. Esta API é de nível muito baixo e não amigável para programadores, então a libcs foi inventada. Eles expõem funções, que são úteis e chamam diretamente a API do kernel.
Fato 1 : A API do kernel do Linux é muito estável, portanto, os aplicativos vinculados estático ao musl antigo podem esperar que o comportamento antigo da API do kernel ainda funcione.
Fato 2 : O musl de link estático no aplicativo faz com que todo o aplicativo chame a API do kernel diretamente.
Fato 3 : O aplicativo compilado com musl static-linked funcionará nas versões atuais e futuras do Linux usando apenas a API do kernel.
Então, por que algumas distros têm suporte musl explícito? Ter uma API de kernel compatível com Linux não é suficiente?
Alguns dos meus "fatos" devem ser inválidos, porque não posso responder minha própria pergunta.
Seus três fatos são precisos o suficiente, pelo menos para entender o que é necessário de uma biblioteca C (em alto nível).
Eu acho que o que é inválido é o seu entendimento de “suporte musl explícito”. Existem três tipos de distribuições do ponto de vista do musl:
Da mesma forma que qualquer outro binário, você pode usar um binário dependente de musl em qualquer distribuição Linux, desde que também forneça as bibliotecas necessárias. Se estiver vinculado estaticamente, não haverá bibliotecas para fornecer. Não há requisitos específicos nas próprias distribuições.
Você pode estar se perguntando sobre o terceiro tipo acima. Fornecer musl em uma distribuição que não depende dele é feito para tornar a vida mais simples para usuários que desejam construir binários usando musl: essas distribuições fornecem as bibliotecas musl (estáticas e dinâmicas, geralmente), arquivos de cabeçalho e suporte ao compilador necessários para construir binários usando musl. Isso significa que os usuários podem começar a construir binários usando o musl sem precisar instalar o musl e configurar seus próprios compiladores.
Em geral, o fato de algumas distribuições suportarem um determinado recurso, enquanto outras não, não significa que esse recurso não possa ser suportado no último; significa que o usuário final precisa fazer o trabalho envolvido.