Re: [Cliente remoto Microsiga AP7] Falha de segmentação
On 5/21/07, Renato S. Yamane <renatoyamane@mandic.com.br> wrote:
Maxwillian Miorim escreveu:
> On 5/21/07, Renato S. Yamane <renatoyamane@mandic.com.br> wrote:
>> Desculpe a minha ignorância, mas o que eu preciso fazer depois disso:
>> $eu-readelf -n ap7rmt
>>
>> Note segment of 32 bytes at offset 0x108:
>> Owner Data size Type
>> GNU 16 VERSION
>> OS: Linux, ABI: 2.2.5
>
> Por exemplo, "LD_ASSUME_KERNEL=2.4.20 ap7rmt" vai executar com a ABI
> 2.4.20, basta definir outras versões e testar. Definindo uma ABI
> específica pode ajudar a resolver este tipo de problema (eu acredito
> que seja compatibilidade entre as bibliotecas).
>
> Esqueci de perguntar antes, quais bibliotecas compartilhadas são
> usadas pelo aplicativo? (ldd ap7rmt)
Eu estou usando o Kernel 2.6.21.1, então posso colocar
"LD_ASSUME_KERNEL=2.4.20 ap7rmt"?
Pode sim, na verdade funciona assim:
Usando 2.2.5 ele vai procurar algumas libs especificas (sistema de
threading, dentre outras capacidades do kernel) em /lib
Usando 2.4.20 ele procura por estas libs em /lib/tls (padrão da 2.4.20
em diante)
Usando 2.4.1 ele procura em /lib/i686
Isso é para confirmar incompatibilidade de bibliotecas "mais baixo nível".
Isso só irá influenciar no ap7rmt, certo?
Sim, e apenas quando utilizares LD_ASSUME_KERNEL para executar o comando.
Quanto ao ldd, eu mencionei no primeiro e-mail, mas segue novamente:
Eu esqueci, fiquei mais focado no backtrace nas últimas mensagens.. :D
Uma solução mais radical seria pegar as libs de um sistema homologado,
colocar em um diretório separado e usar o LD_LIBRARY_PATH apontando
para este diretório durante a execução, é bem parecido com gaiolas de
32bits para sistemas 64bits.
Se o pessoal da Microsiga for camarada eles também podem compilar o
aplicativo estaticamente, gera um binário gigante mas não tem problema
de DSO :)
Reply to: