gcc: Réduire la version requise de libc

Je suis en train de lancer un nouveau binaire compilé sur certaines un peu vieux 32bits distribution RedHat.
Le binaire est compilé en C (pas de++) sur un CentOS 32bits VM en cours d'exécution de la libc v2.12.

RedHat se plaint de la version de la libc:

error while loading shared libraries: nécessite de la glibc 2.5 ou plus tard, l'éditeur de liens dynamiques

Depuis mon programme est assez simpliste, Il n'est probablement pas à l'aide de quelque chose de nouveau à partir de la libc.

Est-il un moyen de réduire version de la libc exigence

source d'informationauteur MonoThreaded

  1. 18

    Non testé solution possible

    Ce qui est "error while loading shared libraries: nécessite de la glibc 2.5 ou plus tard, l'éditeur de liens dynamiques"?

    La cause de cette erreur est la dynamique binaire (ou l'un de ses dépendants
    bibliothèques partagées) que vous souhaitez exécuter .gnu.hachage de la section, mais le
    ld.donc sur la machine cible est trop vieux pour reconnaître .gnu.hash; il ne
    reconnaît la vieille école .hachage de la section.

    Cela se produit généralement lorsque la dynamique binaire en question est construit
    utilisant la nouvelle version de GCC. La solution est de recompiler le code avec
    soit -statique compilateur option de ligne de commande (pour créer un statique
    binaire), ou l'option suivante:

    -Wl,--hash-style=both

    Cela indique à l'éditeur de liens ld pour créer à la fois .gnu.et de hachage .de hachage
    les sections.

    Selon ld la documentation icila vieille école .hachage section
    par défaut, mais le compilateur ne peut le remplacer. Par exemple, la GCC
    (qui est la version 4.1.2) sur RHEL (Red Hat Enterprise Linux) Serveur
    version 5.5 a cette ligne:

    $ gcc -dumpspecs
....
*link:
%{!static:--eh-frame-hdr} %{!m32:-m elf_x86_64} %{m32:-m elf_i386} --hash-style=gnu   %{shared:-shared}   ....
                                                                   ^^^^^^^^^^^^^^^^
...

    Pour plus d'informations, voir ici.

  2. 4

    J'ai déjà eu le même problème, essayez de compiler un petit outil (je l'ai écrit) pour une vieille machine pour laquelle je n'avais pas de compilateur. J'ai compilé sur une mise à jour de la machine, et le binaire requis au moins GLIBC 2.14 pour exécuter la commande.

    En faisant un dump de la binaire (avec xxd), j'ai trouvé ceci :

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

    Je l'ai donc remplacé le memcpy appels dans mon code par un appel à un home-made memcpy, et la dépendance avec la glibc 2.14 comme par magie disparu.

    Je suis désolé, je ne peux pas vraiment expliquer pourquoi ça a marché, je ne peux pas expliquer pourquoi il n'a pas de travail avant la modification.

    Espère que ça a aidé !

  3. 2

    Ok, alors, essayer de trouver un équilibre entre l'élégance et de la force brute, j'ai téléchargé un VM correspondant à la cible noyau version, d'où la fixation de la bibliothèque de questions.

    L'ensemble de la chose (téléchargement + yum install gcc) a pris moins de 30 minutes.

    Références: Les machines virtuelles, La Version Du Noyau Table De Mappage