Tenho 2 bibliotecas de objetos compartilhados, por exemplo, libA.soe libB.so. Tenho um executável que chama funções de ambas as bibliotecas, por exemplo, funcA()from libAe funcB()from libB.
Infelizmente, ambos libAe libBtêm algumas outras funções que usam o mesmo nome de símbolo, por exemplo, libAtem a função f1()e f2()e libBtambém tem as funções f1()e f2(). Observe que as implementações de f1()e f2()são completamente diferentes entre libA e libB, elas são apenas chamadas pelo mesmo nome.
O código executável nunca chama f1()ou f2()diretamente e, é claro, libAdeve chamar apenas seu f1()& f2()e libBdeve chamar apenas seu f1()and f2().
Mas parece que algo deu errado e recebo uma falha de segmentação ao executar o executável.
Tenho uma solução para isso, que é usar um "version.script" ao compilar libAe libB, para que apenas as funções da API externa (ou seja, aquelas chamadas "func*") sejam expostas, ou seja, o seguinte script...
{
global: func*;
local: *;
};
... e usar -Wl,--version-script=version.scriptao vincular com o gcc.
Isso funciona, mas me causa complicações porque tenho que usar uma cadeia de ferramentas de terceiros que torna complexo (ou seja, complicado) usar esse método version.script.
Existe uma maneira melhor/outra? (Observe que eu tenho a fonte para libAe libB, então alterar nomes de símbolos é possível, mas não é do meu agrado, pois esse código é gerado automaticamente por uma ferramenta de terceiros e eu realmente não quero entrar e editar todos os nomes. Claro, o código real não é apenas f1()e , f2()mas centenas de símbolos com nomes semelhantes).
Além disso, eu gostaria de entender a causa raiz do problema? Estou assumindo que libA(ou libB) fica "confuso" com qual f1()ou f2()deveria chamar, mas por que - já que ambos libAe libBsão compilados separadamente - algo a ver com bibliotecas de objetos compartilhados, eu suspeito?
Caso seja importante... a fonte para as bibliotecas e o executável é C, e estou usando gcc para compilar e vincular, e isso está no Linux.