Como faço para manter uma pilha separada (mais recente) de glibc / gcc /… como não-raiz no Linux?

Question

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

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

O problema é que gcc requer um novo glibc do que aquele que está presente na (s) máquina (s). Portanto, preciso manter uma versão separada e mais nova de glibc na minha árvore lib/ local, provavelmente conforme descrito aqui .

Onde estou perdido, como faço para "codificar" os caminhos de minhas bibliotecas locais em todos os binários necessários, ou seja, gcc , g++ etc.? Configurar LD_LIBRARY_PATH para minha árvore lib/ local faz com que todos os binários do sistema não funcionem mais ( ELF file OS ABI invalid ) porque eles querem usar meu novo libm.so / libc.so contra o qual eles não foram compilados.

Então, para finalizar: Qual é a maneira correta de manter uma nova pilha de desenvolvimento local (contendo glibc , gcc etc.) em paralelo a um sistema antigo sem mexer como root?

Como uma questão secundária: A configuração de LD_LIBRARY_PATH é postada como uma solução por toda a SE quando se trata de separar glibc . Para mim, isso causa os erros acima quando tento executar qualquer binário do sistema (como ls ). Por quê? Eu fiz algo errado ou este é o comportamento pretendido?

    

Answer 1

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

1. Use um wrapper em torno de suas bibliotecas, que irá definir LD_LIBRARY_PATH apropriadamente e depois executar a biblioteca desejada - algo como:

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

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

3. Você não vai gostar de ler este aqui: atualize o seu cluster (observe a ênfase em "seu"). Isso terá que ser feito um dia ou outro, então porque não hoje. "Não é uma opção" é um pouco strong 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 embutido neles. E o antigo vinculador dinâmico não entende a nova ABI. Tente chamar os binários assim: path/to/your/ld-linux-<arch>.so binary .

Construindo o GCC: você sempre pode tentar exportar CFLAGS no ambiente de criação do GCC - mas tenho certeza que eles serão propagados. Buildscripts de várias distribuições podem lhe dar algumas pistas (por exemplo: para o openSUSE, olhe em volta da linha 1880 no . Arquivo de especificação ).