Alterando a versão do ld-linux-x86-64.so.2 no RHEL5.7

Question

Estou tentando usar bibliotecas compartilhadas que não funcionam bem com o ld-linux-x86-64.so.2 que é encontrado em / lib64. Eu não tenho acesso root, então não posso alterar o arquivo em / lib64. Existe uma maneira que eu possa dizer a minha caixa RHEL5.7 para usar um ld-linux-x86-64.so.2 diferente? Eu tentei colocar o caminho para a versão que eu preciso usar dentro de $ LD_LIBRARY_PATH, mas ele é ignorado lá.

Eu tenho um executável que vem empacotado com algumas bibliotecas compartilhadas. O executável funciona principalmente com as bibliotecas que já estão localizadas na máquina, mas, de vez em quando, trava e aponta para uma das bibliotecas que estou usando em / lib. Quando eu adiciono algumas das bibliotecas que vieram com o executável para o meu LD_LIBRARY_PATH, ele causa falhas de segmentação para comandos simples como 'ls' 'cp' 'ldd'. Uma versão do ld-linux-x86-64.so.2 também veio com este executável e não causa uma falha seg quando executo o comando ./ld-linux-x86-64.so.2 --list libc.so (ou a outra biblioteca que faz com que os comandos sejam interrompidos). Eu queria ser capaz de testar usando o ld-linux-x86-64.so.2 que veio junto com o software para ter certeza de que ele cuidou dos problemas (e não causou outros) antes de ir para a TI e fazendo com que eles façam alterações em todas as caixas nas quais executaremos o software. Ou, se possível, crie o trabalho em meu script de trabalho para que eu não precise passar por todo o processo de solicitação de mudança.

Um sintoma do libc.so incluído não está jogando bem com ld-linux.so é quando eu tento fazer um comando é o seguinte. cp: relocation error: libc.so.6: símbolo _dl_tls_get_addr_soft, versão GLIBC_PRIVATE não definida no arquivo ld-linux-x86-64.so.2 com referência de tempo de link Eu sou o único que usa a minha máquina, mas a minha empresa não dá acesso root aos usuários, porque a forma como a rede é configurada, se você tem raiz em uma caixa de linux você tem em todos eles.

    

Answer 1

Desculpe por essa "resposta", tentei colocar isso em um comentário sobre sua pergunta, mas o espaçamento e a formatação são limitados.

O ld-linux-x86-64.so.2 é uma parte essencial do seu sistema operacional. Na verdade, ele executa todos os aplicativos dinâmicos (64 bits). Não é uma biblioteca tanto quanto um aplicativo em si, um manipulador que é chamado quando você executa um aplicativo.

Basicamente, quando você executa um aplicativo dinâmico, o kernel primeiro executa o ld-linux.so (ou qualquer outro nome que seja para o seu bitsize, distro, etc). O ld-linux.so, então, perscruta seu aplicativo, vê as bibliotecas de que você precisa, vê quaisquer caminhos codificados para as bibliotecas (por exemplo, rpath) verificam LD_LIBRARY_PATH e, em seguida, procuram por todas essas bibliotecas, garantem que combinem bitsizes, nomes, o que você tem. Em seguida, ele coleta todos os itens, carrega-os e executa seu aplicativo. Se não conseguir encontrar as bibliotecas, ele não executará seu aplicativo.

O ld-linux.so não pode ser afetado pelo LD_LIBRARY_PATH porque ele é executado pelo kernel, e o kernel não carrega bibliotecas como o ld-linux.so, ele apenas tem o que está configurado para ser executado. Novamente, não uma biblioteca, portanto, não use a semântica da biblioteca (LD_LIBRARY_PATH) para alterar como ela é chamada. Ele possui variáveis de ambiente que o afetam em execução - veja man ld-linux.so para detalhes (além de LD_LIBRARY_PATH, LD_PRELOAD é muito útil).

Eu ficaria muito interessado em saber qual é o seu problema. Sem ofensa, mas isso parece ser um Problema X-Y . Novamente, esta é uma parte do sistema operacional core . Se estiver quebrado, seu sistema operacional será quebrado. Se você quiser trocá-lo, você provavelmente afetaria ( ler : quebrar horrivelmente) o resto do seu sistema. Já que você não tem raiz, eu assumo que você não é o único nessa caixa, e você ficaria com raiva de algumas pessoas. :)

O que você está tentando fazer?

    

Answer 2

Adicionando outra resposta, porque a outra resposta foi mais uma fala / reclamação de qualquer maneira.

Parece que você não tem um problema no ld-linux.so, mas é mais provável que haja um problema simples de incompatibilidade de biblioteca. Provavelmente versões - RHEL 5 não é mais a versão atual do RHEL, portanto não é mais vanguarda, e a glibc, em particular, teve problemas nas versões.

Eu colocaria seu executável em um script de shell simples que definiria LD_LIBRARY_PATH para suas bibliotecas especiais e, em seguida, executaria seu aplicativo. Dessa forma, seus outros aplicativos (ls, cs, etc) não serão afetados por essas novas bibliotecas. No seu script você poderia até usar o novo ld-linux.so para rodar seu aplicativo no script, se isso ajudasse. Eu acho que não, mas você pode testá-lo. Desta forma, tudo é isolado para o script, o novo executável e as bibliotecas específicas que o acompanham.