O meu binário do Linux funcionará em todas as distros?

Question

Eu encontrei um bom substituto IDE para Delphi chamado Lazarus. Mas eu não tenho uma pergunta para programadores.

O trabalho binário do Linux estaticamente vinculado em todas as distribuições Linux? Ou seja não importa qual distro Linux eu construí e funcionará no Debian / ArchLinux / Ubuntu / OpenSUSE / ... o que for?

Como resultado das minhas descobertas, realmente importa apenas 32bit vs 64bit? Eu quero ter certeza antes de publicar.

    

Answer 1

Esta resposta foi escrita pela primeira vez para a questão mais geral "meu binário será executado em todas as distros", mas trata de binários estaticamente vinculados no segundo semestre.

Para qualquer coisa que seja mais complexa do que um mundo hello vinculado estaticamente, a resposta é provavelmente não . Sem testá-lo na distribuição X, assuma que a resposta é não para X.

Se você quiser enviar seu software em formato binário, restrinja-se a

• algumas distribuições populares para o campo de uso de seu software (desktop, servidor, incorporado, ...)

• a última ou duas versões de cada

Caso contrário, você acabará com centenas de distribuições de todos os tamanhos, versões e idades (as distribuições de dez anos ainda estão em uso e suportadas).

Teste para eles. Apenas alguns apontamentos sobre o que pode (e vai) dar errado de outra forma:

• O pacote de uma ferramenta / biblioteca que você precisa tem um nome diferente nas distribuições e até nas versões da mesma distribuição

• As bibliotecas de que você precisa são muito novas ou antigas (versão incorreta). Não assuma apenas porque o seu programa pode vincular, ele se vincula à biblioteca certa.

• A mesma biblioteca (arquivo no disco) é nomeada de forma diferente em distribuições diferentes, tornando a vinculação impossível

• 32 bits em 64 bits: o ambiente de 32 bits pode não estar instalado ou uma biblioteca não essencial de 32 bits é movida para um pacote extra além do ambiente 32on64, portanto você tem uma dependência extra apenas para este caso.

• Shell: não assuma sua versão do Bash. Não assuma nem Bash.

• Ferramentas: não assuma que alguma ferramenta de linha de comando não POSIX existe em qualquer lugar.

• Ferramentas: não assuma que a ferramenta reconheça uma opção apenas porque a versão GNU de sua distribuição faz.

• Interfaces do kernel: não assuma a existência ou estrutura de arquivos em /proc apenas porque eles existem / têm a estrutura em sua máquina

• Java: você tem certeza de que seu programa é executado no JRE da IBM fornecido com o SLES sem testá-lo?

Bônus:

• Conjuntos de instruções: o binário compilado em sua máquina não é executado em hardware mais antigo.

A vinculação estática (ou: agrupar todas as bibliotecas necessárias com o software) é uma solução? Mesmo que funcione tecnicamente, os custos associados podem ser altos. Então, infelizmente, a resposta provavelmente não é nenhuma delas.

• Segurança: você muda a responsabilidade de atualizar as bibliotecas do usuário do seu software para si mesmo.

• Tamanho e complexidade: apenas por diversão, tente criar um programa GUI vinculado estaticamente.

• Interoperabilidade: se o seu software é um "plugin" de qualquer tipo, você depende do software que o chama.

• Design da biblioteca: se você vincular seu programa estaticamente ao GNU libc e usar serviços de nomes ( getpwnam() etc.), você será vinculado dinamicamente ao NSS (switch de serviço de nome) da libc.

• Design da biblioteca: a biblioteca que você vincula estaticamente ao seu programa usa arquivos de dados ou outros recursos (como fusos horários ou localidades).

Por todas as razões mencionadas acima, o teste é essencial.

• Familiarize-se com o KVM ou outras técnicas de virtualização e tenha uma VM com todas as distribuições que você pretende suportar. Teste seu software em todas as VMs.

• Use instalações mínimas dessas distribuições.

• Crie uma VM com um conjunto de instruções restritas (por exemplo, sem SSE 4).

• Vinculado estatisticamente ou somente em pacote: verifique seus binários com ldd para ver se eles estão realmente vinculados estaticamente / usam somente as bibliotecas que você agrupa.

• Vinculado estaticamente ou somente agrupado: crie um diretório vazio e copie o software para ele. chroot nesse diretório e execute seu software.

Answer 2

A resposta é depende. , mas na maioria dos casos, sim, contanto que as bibliotecas necessárias estejam instaladas no SO.

Geralmente, a maioria das principais distros, como as que você mencionou, tem suas ferramentas de gerenciamento de pacotes que instalam a versão mantida pela comunidade do aplicativo. Isso cuida de todos os pacotes de pré-requisitos que o aplicativo precisará. Se você estiver instalando-o sem um gerenciador de pacotes, cabe a você certificar-se de que todos os pacotes e bibliotecas necessários estejam instalados no sistema operacional. É uma boa ideia incluir uma lista desses aplicativos de pré-requisito na documentação.

    

Answer 3

Resposta ruim primeiro: Depende

Se você está liberando binários, suponha que a resposta seja "não", a menos que você esteja distribuindo todas as bibliotecas que sempre envolvem (de baixo para cima, o que é irritante, a menos que você esteja fornecendo um sistema realmente enorme que esteja de qualquer maneira) ou esteja vinculando estaticamente o equivalente.

... mas magos e dinheiro e magos de dinheiro ...

A IBM tem alguns instaladores "Unixish gerais" que me chocaram, trabalhando em todos os lugares que eu os experimentei: vários Linuces de várias gerações de kernel, OpenSolaris (ou o que quer que seja chamado agora), Solaris e BSD. Mas eles são enormes. E as coisas que eles fornecem são igualmente enormes. Nenhum programa de carros de corrida pequeno é publicado dessa forma, apenas o tipo de coisa de grande empresa que você esperaria da IBM.

No que diz respeito a ficar no Linux, mas funcionando bem na maioria dos Linuxdom, isso parece ser possível na forma binária, como evidenciado pela variedade de instaladores binários do tipo "para Linux (geral)" que você verá de alguns fornecedores. Vários chat, navegador, jogo, meta-instaladores, etc. são publicados desta forma, mas sempre por grandes fornecedores que podem gastar tempo para fazer isso direito. É incrível que eles possam dizer "pelo Linux" e ter certeza de que funcionará, mas esse parece ser o caso.

Mas ...

Eu distribuo meu software como fonte com um utilitário de compilação. Eu faço isso em C, Erlang, Python, Guile, etc. Isso me dá um muito maior flexibilidade sobre se ele será executado ou não, e é muito mais fácil escrever um buildscript que garanta o direito existem coisas no tempo de compilação do que para garantir que tudo esteja em execução no tempo de execução. Uma vez que isso exista, é trivial escrever um auto-atualizador para o seu programa se você distribuir a fonte: source é geralmente muito menor que um binário que inclui todos os deps e outras insanidades. Usando esse método, não tive muita dificuldade para implantar de forma confiável nos Unices (e às vezes no Windows, mas isso é um pouco mais complicado).

Chega de brincadeira, arme-se!

Quando você está ficando sério, como srsly srs, sobre o ajuste perfeito dentro do mundo Linux, você distribui fontes C ou para um ambiente totalmente gerenciado para uma linguagem deliciosa que já está pré-construída. Se você estiver escrevendo código Python, por exemplo, você pode verificar versões e saber com qual versão o CPython trabalha, e geralmente esperar que alguma versão compatível exista em um determinado Linux (e isso é muito mais fácil de verificar do que uma ampla varredura de C libs / versões que você pode estar usando). Erlang, Guile, Python, Perl, CL, etc. são todos alvos muito fáceis para este tipo de implementação, e muitos deles têm um repositório central como CPAN ou pip (ou qualquer outro) onde os usuários podem rodar. um comando para puxar a fonte assinada quando quiser e saber que as coisas geralmente funcionam como você pretendia.

[Adendo: 1. Até mesmo Haskell geralmente consegue isso através da Cabal - embora eu seja cauteloso em fazer isso em um ambiente de produção. 2. Existem estratégias de implementação de "lançamento" totalmente diferentes com o Erlang que garantem que o seu código carrega um ambiente completo em torno dele. 3. Python vai um passo adiante com ambientes virtuais; nem todos os tempos de execução o ajudam tanto.]

Este último bit sobre ambientes gerenciados no Linux é incrível . E, como bônus, permite definir dependências muito mais gerais, resolvê-las automaticamente sem nenhum esforço extra de sua parte, não requer escrever um pacote por distro, e você pode parar de se importar se um sistema é 32 ou 64 bits (geralmente, de qualquer maneira).