Suponha que eu queira criar um pacote com várias bibliotecas compartilhadas - chame-o de libfoo , que contém liba.so.1 e libb.so.1 . Agora, digamos que liba.so.1 usa um símbolo de libb.so.1 . Se eu compilar assim, então está tudo bem:
cc -shared -fPIC -Wl,-soname,libb.so.1 -o libb.so.1 libb.c cc -shared -fPIC -Wl,-soname,liba.so.1 -o liba.so.1 liba.c libb.so.1
No entanto, isso requer algum trabalho extra (eu tenho que descobrir manualmente as dependências e codificá-las no meu makefile, e o scons não parece fazer isso automaticamente). Compilar a maneira fácil cria um problema interessante:
cc -shared -fPIC -Wl,-soname,libb.so.1 -o libb.so.1 libb.c cc -shared -fPIC -Wl,-soname,liba.so.1 -o liba.so.1 liba.c
Agora, liba.so.1 não tem libb.so.1 no cabeçalho DT_NEEDED (visível usando objdump -p ) e, ao criar um pacote debian, recebo a seguinte mensagem (e essa etapa demora MUITO mais):
dh_shlibdeps dpkg-shlibdeps: warning: symbol b used by debian/libfoo1/usr/lib/liba.so.1 found in none of the libraries.
Isso acontece porque o símbolo b está definido em libb.so.1 , mas dpkg-shlibdeps não tem como saber isso.
Devo observar que não parece haver um problema real aqui - o binário real tem liba e libb como DT_NEEDED , e ambos são carregados em tempo de execução ... foram por anos. Este problema só surgiu quando tentamos criar um pacote Debian correto e de construção limpa.
Como devo resolver isso? ( devo eu resolver isso?) As bibliotecas devem realmente (TM) estar no mesmo pacote debian. (Para pontos de bônus, resolva dependências circulares, ou seja, libb também usa um símbolo de liba ).