Como mantenho uma pilha glibc / gcc /… separada (mais recente) como não raiz no Linux

Nosso cluster de computação executa uma versão muito antiga do CentOS, com um Kernel antigo (2.6.18) e, é claro, bibliotecas e binários antigos. Como atualizar a coisa toda exige muito trabalho em todos os nós, isso não é uma opção.

Estou tentando compilar e usar um programa que requer C++11e, portanto, versões mais recentes de gcc(e / ou clang). Como eu não quero mexer com o sistema, quero fazer isso como um usuário não raiz em alguma árvore de diretórios local.

O problema é que isso gccrequer um mais novo glibcque o presente na (s) máquina (s). Portanto, preciso manter uma versão separada e mais recente da glibcminha lib/árvore local , provavelmente como descrito aqui .

Onde estou perdido, como codifico os caminhos das minhas bibliotecas locais em todos os binários necessários, por exemplo gcc, g++etc.? Definir LD_LIBRARY_PATH como minha lib/árvore local faz com que todos os binários do sistema não funcionem mais ( ELF file OS ABI invalid) porque eles querem usar o meu novo libm.so/ libc.socontra o qual não foram compilados.

Assim, para envolvê-lo: O que é a maneira correta de manter, uma pilha mais recente desenvolvimento local (contendo glibc, gccetc.) em paralelo com um sistema antigo sem mexer como root?

Como uma pergunta secundária: A configuração de LD_LIBRARY_PATH é publicada como uma solução em todo o SE quando se trata de separar glibc. Para mim, isso causa os erros acima quando tento executar qualquer sistema binário (como ls). Por quê? Fiz algo errado ou esse é o comportamento pretendido?

Você tem basicamente três opções:

1. Use um wrapper em torno de suas bibliotecas, que será configurado LD_LIBRARY_PATHadequadamente e, em seguida, execute a biblioteca desejada - algo como:

   #!/bin/sh
   export LD_LIBRARY_PATH="path/goes/here"
   exec "$@"
   

2. link with -rpath( -Wl,rpath), que adiciona o caminho de busca do vinculador dinâmico ao binário (consulte também a resposta SO - também menciona o wrapper).

3. Você não vai gostar de ler este: atualize seu cluster (observe a ênfase em "seu"). Isso terá que ser feito um dia ou outro, então por que não hoje? "Não é uma opção" é um pouco forte na maioria dos casos. Outros usuários provavelmente têm os mesmos problemas.

Quanto aos binários antigos com problemas - os binários têm seu vinculador dinâmico preferido incorporado. E o vinculador dinâmico antigo não entende a ABI mais nova. Tente chamar os binários como este: path/to/your/ld-linux-<arch>.so binary.

Criando o GCC: você sempre pode tentar exportar CFLAGSno ambiente de criação do GCC - mas tenho certeza que eles são propagados. Os scripts de construção de várias distribuições podem fornecer algumas dicas (por exemplo: para o openSUSE, consulte a linha 1880 no arquivo .spec ).