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 Jean-Christophe Berthon (site web personnel) . Évalué à 2.
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:
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!
[^] # Re: Comment j'ai procédé jusqu'à présent
Posté par Christophe Chailloleau-Leclerc . Évalué à 2.
(genre LIBPATH, LD_LIBRARY_PATH ou je ne sais plus quelle variable sous Linux).
Juste en passant, hein, je n'ai lu qu'en diagonale ;)
[^] # Re: Comment j'ai procédé jusqu'à présent
Posté par Jean-Christophe Berthon (site web personnel) . Évalué à 2.
Je viens de faire un nouveau test. Je suis allé sur une RedHat 7.3 qui contient déjà la glibc 2.2.5 que l'on tente d'installer sur la RedHat 8 en parallèle de celle par défaut.
J'ai pris mon petit bout de programme, je l'ai compilé avec gcc, et ça marche. Donc il n'y a pas d'erreur dans mon code ;-) déjà.
Ensuite j'ai utilisé plus ou moins la même ligne de commande que sur l'autre système pour compiler (juste en adaptant les chemins de /usr/local vers /usr ou /lib) ce qui donne ce qui suit :
gcc -g -nostdinc -I/usr/include -I/usr/lib/gcc-lib/i386-redhat-linux/2.96/include -nostdlib -L/usr/lib -L/usr/lib/gcc-lib/i386-redhat-linux/2.96 /lib/libc-2.2.5.so -b i386-redhat-linux shueber.c
/usr/bin/ld: warning: cannot find entry symbol _start; defaulting to 08048184
Et en exécutant, j'ai le même comportement que je rapportais dans mon précédent message : i-e segfault.
Donc j'ai un problème dans ma compilation. Est-ce que quelqu'un a déjà utilisé les flags de compile -nostdinc et -nostdlib?
Merci
[^] # Re: Comment j'ai procédé jusqu'à présent
Posté par gc (site web personnel) . Évalué à 2.
# J'y suis presque mais j'ai encore besoin d'aide
Posté par Jean-Christophe Berthon (site web personnel) . Évalué à 2.
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 gc (site web personnel) . Évalué à 3.
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 Pat Le Nain . Évalué à 2.
si ça peux t'aider ...
# chroot
Posté par Anonyme . Évalué à 2.
juste une idée comme ça
[^] # Re: chroot
Posté par Jean-Christophe Berthon (site web personnel) . Évalué à 2.
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.