Forum Programmation.c Utiliser 2 versions de la glibc en parallèle

Posté par  (site web personnel) .
Étiquettes : aucune
0
4
août
2004
Bonjour,

Je souhaite utiliser 2 versions de la glibc différentes sur le même système (un peu comme un développeur voudrait tester une version nouvelle encore en phase de dev de la glibc tout en conservant pour son système sa glibc stable).

Bref comment fait-on? Ou plutôt comment faîtes-vous?

Merci,
Jean-Christophe
  • # Comment j'ai procédé jusqu'à présent

    Posté par  (site web personnel) . Évalué à 2.

    Si vous ne savez pas répondre à ces questions, peut-être saurez-vous voir mon erreur dans ma méthode. Voilà comment j'ai procédé moi-même :

    J'ai réussi à compiler une 2ème glibc et à l'installer dans /usr/local. J'ai ensuite réussi à compiler mon programme "Hello World". Quand j'utilise ldd le résultat est correct. Mais quand j'exécute mon programme, j'obtiens un signal 11 (segfault) une fois toutes les instructions effectuées.

    Je pense donc que je dois avoir une erreur dans ma façon de compiler ou d'exécuter mon programme.

    Pour info:
  • RedHat 8 (glibc 2.3)
  • Installation glibc 2.2.5 sous /usr/local
  • compilation en utilisant -nostdinc et -nostdlib, et en précisant les -I et -L sous /usr/local. Utilisation du -b glibc-2.2.5 où se répertoire contient le fichier "specs" de gcc avec le libld.so sous /usr/local.


    Mon programme Hello World:
    #include <stdio.h>

    int main()
    {
    printf("Hello.\n");
    return 0;
    }

    Au débuggeur, le printf et le return sont exécutés (utilisation de step au lieu de next sous gdb), et ensuite j'ai le signal 11 qui arrive!
  • # J'y suis presque mais j'ai encore besoin d'aide

    Posté par  (site web personnel) . Évalué à 2.

    J'ai réussi à compiler de manière plus propre le programme :
    gcc -g -Dlinux -D__linux__ -Dunix -fno-builtin -nostdinc -I/usr/include -I/usr/lib/gcc-lib/i386-redhat-linux/2.96/include -b i386-redhat-linux -c -o shueber.o shueber.c
    gcc -nostartfiles -nostdlib -L/usr/lib -L/usr/lib/gcc-lib/i386-redhat-linux/2.96 /lib/libc-2.2.5.so /usr/lib/crt{1,i}.o -b i386-redhat-linux shueber.o -lgcc

    Mais lors de l'exécution, je n'atteinds plus l'instruction printf. Il plante dans les processus init. Voir la backtrace de gdb :
    (gdb) bt
    #0 fixup (l=0x40014850, reloc_offset=269026572) at dl-runtime.c:60
    #1 0x40009f10 in _dl_runtime_resolve () from /lib/ld-linux.so.2
    #2 0x4002e71a in __libc_start_main (main=0x80482c0 , argc=1,
    ubp_av=0xbfffe354, init=0x804823c <_init>, fini=0x80482e0 <_fini>,
    rtld_fini=0x4000a560 <_dl_fini>, stack_end=0xbfffe34c)
    at ../sysdeps/generic/libc-start.c:122

    Si vous pouviez avoir une info ou une soluce ça serait cool. merci d'avance :-)
    • [^] # Re: J'y suis presque mais j'ai encore besoin d'aide

      Posté par  (site web personnel) . Évalué à 3.

      J'allais te suggérer /usr/lib/crt1.o mais tu l'as trouvé tout seul.

      Effectivement, il me semble que l'on ne peut pas générer d'éxecutable C valide sans quelques éléments traditionnellement fournis implicitement par la glibc que sont les symboles de début/fin d'éxecution du programme (des choses qui ressemblent au main() en fait, si tu fais "nm /usr/lib/crt1.o" tu en verras). Il faut donc t'assurer que ce sont les bons qui sont fournis, et qu'aucun n'est omis (syndrome du warning de ld plus haut). Je ne les connais pas par coeur mais je sais qu'il faut au moins trouver _environ _init __libc_init_first __libc_csu_fini __libc_csu_init __libc_start_main _fini atexit exit, si j'en crois la "minilibc" de redhat). Au pire, tu peux toujours en mettre dans ton programme si tu peux te le permettre, voir le contenu de http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/~checkout~/gi/mdk-st(...)

      Sinon, pour gdb, je ne suis pas sûr en fait que ce qu'il dit soit correct car lui aussi doit bien trouver quelque part les symboles, enfin, je ne saurais trop comment l'expliquer mais je ne me fierais pas à ses résultats comme cela.

      Bon, bref, bonne chance, c'est pas évident de se débrouiller avec ton problème, mais en même temps ça doit être très instructif.
    • [^] # Re: J'y suis presque mais j'ai encore besoin d'aide

      Posté par  . Évalué à 2.

      il ya l'option -rpath de GNU ld qui permet d'ajouter un répertoire à la liste des répertoires où rechercher les .so à l'exécution (c'est le pendant le -L)

      si ça peux t'aider ...
  • # chroot

    Posté par  . Évalué à 2.

    si c'est pour faire des essais, dans un premier temps ne serais ce pas plus simple de le faire dans un environnement chrooté?

    juste une idée comme ça
    • [^] # Re: chroot

      Posté par  (site web personnel) . Évalué à 2.

      Effectivement ça permettrait de vérifier que la glibc a bien été généré au moins.
      Mais dans un deuxième temps on aura besoin de la cohabitation des deux bibliothèques...
  • Suivre le flux des commentaires

    Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.