programa - gcc: reduce libc versión requerida

gcc version (3)

Bien, entonces, tratando de encontrar un equilibrio entre la elegancia y la fuerza bruta, descargué una máquina virtual que coincide con la versión del kernel de destino , por lo que solucioné los problemas de la biblioteca.
Todo el proceso (descargar + yum install gcc) tomó menos de 30 minutos.

Referencias: máquinas virtuales , tabla de mapeo de versiones del kernel

Estoy tratando de ejecutar un binario recién compilado en alguna distribución RedHat de 32 bits.
El binario se compila en C (no ++) en una máquina virtual CentOS 32bits que ejecuta libc v2.12.

RedHat se queja de la versión libc:

error while loading shared libraries: requires glibc 2.5 or later dynamic linker Como mi programa es bastante simplista, lo más probable es que no use nada nuevo de libc.

¿Hay una manera de reducir el requisito de versión libc

Una posible solución no probada.

¿Qué es el "error al cargar bibliotecas compartidas: requiere glibc 2.5 o posterior enlazador dinámico"?
La causa de este error es el binario dinámico (o una de sus bibliotecas compartidas dependientes) que desea ejecutar solo tiene la sección .gnu.hash, pero el ld.so en la máquina de destino es demasiado antiguo para reconocer .gnu.hash; solo reconoce la seccion .hash de la vieja escuela.
Esto suele suceder cuando el binario dinámico en cuestión se crea utilizando una versión más reciente de GCC. La solución es recompilar el código con la opción de línea de comandos del compilador estático (para crear un binario estático), o la siguiente opción:
-Wl,--hash-style=both
Esto le dice al editor de enlaces ld que cree las secciones .gnu.hash y .hash.
De acuerdo con la documentación de ld aquí , la sección .hash de la vieja escuela es la predeterminada, pero el compilador puede anularla. Por ejemplo, el GCC (que es la versión 4.1.2) en el servidor RHEL (Red Hat Enterprise Linux) versión 5.5 tiene esta línea:
$ gcc -dumpspecs .... *link: %{!static:--eh-frame-hdr} %{!m32:-m elf_x86_64} %{m32:-m elf_i386} --hash-style=gnu %{shared:-shared} .... ^^^^^^^^^^^^^^^^ ...
Para más información, ver aquí .

Ya tenía el mismo problema, tratando de compilar una pequeña herramienta (que escribí) para una máquina antigua para la que no tenía compilador. Lo compilé en una máquina actualizada, y el binario requería al menos GLIBC 2.14 para poder ejecutarse.

Al hacer un volcado del binario (con xxd), encontré esto:

.... 5f64 736f 5f68 616e 646c 6500 6d65 6d63 _dso_handle.memc 7079 4040 474c 4942 435f 322e 3134 005f py@@GLIBC_2.14._ ....

Así que reemplacé las llamadas memcpy en mi código por una llamada a un memcpy hecho en casa, y la dependencia con el glibc 2.14 desapareció mágicamente.

Lo siento, realmente no puedo explicar por qué funcionó, o no puedo explicar por qué no funcionó antes de la modificación.

Espero que haya ayudado!