• [^] # Re: glibc 2.0

    Posté par . En réponse au journal glibc 2.0. Évalué à 2.

    Juste une petite correction... pour l'exactitude.

    Le programme ne tente pas d'acceder a un symbole GLIBC_2.0. En fait il tente d'acceder au symbole errno (la variable qui contient le numero de la derniere erreur générée) version GLIBC_2.0.

    En effet, les librairies ELF permettent de définir des symboles versionnés. C'est à dire qu'on peut avoir une fonction foo() version VERSION1 et une autre VERSION2, les deux différents par leur ABI. Le linker fait sa petite affaire ensuite au moment de la relocation de l'executable+libs. C'est une feature qui meme si je la connais me reste totalement inconue dans la pratique et je ne connais guere que la glibc qui l'utilise.

    Dans la glibc, les versions permettent par exemple de distinguer errno sous forme de variable (pas thread safe) de errno() qui retourne le code d'erreur correctement pour chaque thread. Les détails je les connais pas mais cette ruse de sioux fonctionne :-)

    Par contre j'ai aucune solution propre sauf l'installation de la libc correspondante qq part (disons ${vieille_libc}) et de lancer le programme avec:
    LD_PRELOAD=${vieille_libc}/libc.so.5(<-- version de la glibc 2.0 iirc) maple

    Mais je garantis pas le resultat du tout, d'autres libs chargées par maple pouvant peut etre avoir besoin, elles, d'une glibc plus recente.