Como foi dito nos comentários, a única maneira confiável de construir um único binário que funcionará em diferentes versões do Debian (ou qualquer distribuição do Linux) é compilá-lo estaticamente. Isso é bem suportado no Debian e em outros lugares, inclusive com pkg-config
etc. Os binários estáticos podem continuar funcionando por décadas; a interface do userspace do kernel é mantida de forma compatível com versões anteriores (às vezes, ela é interrompida, mas isso é considerado um bug e geralmente corrigido rapidamente). Você encontrará casos em que os binários estáticos param de funcionar, mas isso geralmente está relacionado a libnss
handling (isso é dinâmico mesmo em binários estáticos) ou a mudanças nas expectativas do servidor X (isso acontece com jogos Linux antigos ), ou núcleos de distribuição eliminando o suporte para recursos considerados obsoletos ( por exemplo a interface de som OSS em kernels Ubuntu).
(Outra abordagem é enviar todas as suas bibliotecas dependentes e usar rpath
ou um shell script para configurar as coisas corretamente; isso é o que o Steam faz, e muitos jogos Linux que não são Steam fazem isso também, mas é menos futuro prova de ligação estática e é mais difícil de corrigir quando as coisas dão errado.)
Seu binário dinâmico embutido no Debian 6 funciona no Debian 8 porque as dependências diretas do binário ainda estão disponíveis em sua instalação do Debian 8; isso é pura sorte e não é algo em que você possa confiar. Por exemplo, seu binário está vinculado a libssl.so.0.9.8
; que ainda funciona para você no Debian 8, porque você ainda tem o antigo pacote libssl0.9.8
(note que o link é satisfeito por /usr/lib/i686/cmov/libssl.so.0.9.8
, que não usa um caminho multiarch e presumivelmente vem de um pacote antigo). Baseando-se no Debian 8 sem pacotes antigos, você acabaria com um link para libssl.so.1.0.0
, e isso não está disponível na Debian 6. (Esta é a situação na qual você terminaria com um Debian 8 recém-instalado. sistema.)
Seu binário construído em Debian 8 não funciona no Debian 6, e isso é perfeitamente normal: a compatibilidade binária é apenas crescente, não decrescente. Isto significa que se você construir um binário no Debian 6, e ele ainda encontrar suas bibliotecas no Debian 8, então ele deve funcionar bem; mas um binário ligado no Debian 8 pode esperar símbolos em bibliotecas que não estão disponíveis no Debian 6, sem uma mudança nos sons das bibliotecas. O erro que você recebe em relação a g_thread_create
acontece porque você construiu no Debian 8, onde libglib-2.0.so.0
tem esse símbolo, mas libglib-2.0.so.0
do Debian 6 não. Se você construísse um pacote contendo seu binário, as dependências do pacote o identificariam corretamente (você obteria uma dependência de pelo menos libglib2.0-0 (>= 2.31.8)
; o Debian 6 teria apenas a versão 2.24.2).
A melhor maneira de preparar sua configuração para o futuro é produzir um pacote fonte com dependências que possam ser satisfeitas no Debian 6 e 8; então você pode facilmente construir pacotes binários corretos para o Debian 6, 7, 8, 9 ... Isso é um pouco mais complicado do que construir um binário estático, pelo menos nas primeiras vezes que você faz isso, mas eu acho que vale a pena execute se você planeja fazer esses tipos de atualizações no futuro. Normalmente você usaria pbuilder
para isso, ele suporta construção de várias distribuições ( sbuild
também pode fazer isso). Estender as instruções que eu coloquei lá para o Debian 6 deve ser relativamente fácil (duplique o STABLE_CODENAME
handling para OLDOLDSTABLE_CODENAME
e use os repositórios de arquivos ).