Utilizando um novo glibc autônomo [duplicado]

Question

Estamos executando o RHEL6, que só suporta oficialmente o glibc 2.12. Um usuário está solicitando que instalemos uma versão mais recente.

Eu peguei 2.18 do link e não tive problemas para executar o configure / make.

No entanto, quando tento um pequeno programa para testá-lo, não obtenho o resultado desejado:

test.c

#include <stdio.h>
#include </scratch/new-glibc-testing/include/gnu/libc-version.h>
int main (void) { puts (gnu_get_libc_version ()); return 0; }

Eu então compilo e corro com:

gcc test.c
./a.out

E a saída que recebo é:

2.12

quando esperava chegar:

2.18

Eu também tentei:

gcc -I/scratch/new-glibc-testing/include test.c

e alterou a linha de definição para:

#include <gnu/libc-version.h>

que compila, mas dá o mesmo resultado (2.12).

Eu também tentei usar o -nostdlib, ex:

gcc -nostdlib -I/scratch/new-glibc-testing test.c

Isso, no entanto, gera erros:

/usr/bin/ld: warning: cannot find entry symbol _start; defaulting to 0000000000400144
/tmp/cc6x03Do.o: In function 'main':
test.c:(.text+0x5): undefined reference to 'gnu_get_libc_version'
test.c:(.text+0xd): undefined reference to 'puts'
collect2: ld returned 1 exit status

gcc --version resultados em: gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)

    

Answer 1

Também é necessário especificar o caminho do link (-L -l) sinalizadores - apenas especificar as inclusões não é suficiente (na verdade, você está arriscando falhas do aplicativo ao usar cabeçalhos de uma versão e bibliotecas de uma diferente) . Você também pode precisar das opções -rpath e -rpath-link passadas para o vinculador, dependendo da sua configuração.

Como mencionado nos comentários, é bastante difícil e perigoso manter várias versões do glibc na mesma imagem de máquina. Uma abordagem mais segura é configurar um contêiner "slim" (como chroot jail ou usando lx) e instalar nele uma imagem do sistema diferente com bibliotecas atualizadas conforme necessário.