Le 05/10/07, HAMMER Cédric Ext
ROSI/DPS<[EMAIL PROTECTED]> a écrit :
>
> Hello Eric,
>
> Voici donc le message que j'avais envoyé et qui n'est pas passé (en espérant
> que ce ne soit pas trop gros cette fois) ;).
Il est passé mais je coupe la suite (que j'ai lu :=)
pour alléger la réponse.
Je prie les techno-phobes sensibles qui èrent légitimement sur
cette liste d'ignorer les technicochonneries qui suivent :=).
Je dis ça afin de ne pas nuire à l'image du logiciel libre,
la discussion qui suit ne reflètent pas ce que doit connaitre un
utilisateur "normal" de logiciels libres.
M'enfin évidemment vous êtes libres comme nos chers logiciels :)
>
> Au final, mon problème est quasi résolu grâce à toi, car j'ai réussi à
> construire le rpm, mais maintenant j'aimerai bien savoir comment "nettoyer"
> le premier de ses références à glibc_2.3.4 pour les prochaines constructions
> de rpm ... Tu as une idée d'où pourrai(en)t se trouver cette(ces) entrée(s) ??
Je pense comme toi que l'install avortée de la glibc-2.3.4 a laissé des traces.
Ce doit être un des scripts 'find-requires' qui "génére" la fausse dépendance.
Pour vérifier tu peux essayer la chose suivante:
1) repérer les différents scripts find-requires par exemple:
locate rpm | grep requires
ce qui sur ma machine fedora 7 donne:
/usr/lib/rpm/find-requires
/usr/lib/rpm/find-requires.perl
/usr/lib/rpm/mono-find-requires
/usr/lib/rpm/redhat/find-requires
/usr/lib/rpm/redhat/find-requires.ksyms
/usr/lib/rpm/redhat/find-requires.libtool
/usr/lib/rpm/redhat/find-requires.pkgconfig
2) lancer le/les script/s sur ton exécutable par exemple:
echo /bin/bash | /usr/lib/rpm/find-requires ldd
ce qui chez moi donne:
libc.so.6
libdl.so.2
libtinfo.so.5
linux-gate.so.1
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.2)
libc.so.6(GLIBC_2.3)
libc.so.6(GLIBC_2.3.4)
libc.so.6(GLIBC_2.4)
libdl.so.2(GLIBC_2.0)
si tu veux plus de détails sur l'exécution d'un script 'find-requires' tu peux
aussi faire:
echo /bin/bash | /bin/bash -x /usr/lib/rpm/find-requires ldd
Mon hypothèse est que lors de l'installation avortée de la glibc
la commande /usr/bin/ldd correspondant à la glibc 2.3.4 a été installée
à la place de l'ancienne et que c'est elle qui te "génére" cette dépendance
factice.
Tu peux vérifier la version de ldd en faisant ldd --version.
Tu peux aussi lancer la commande suivante sur ton binaire proftpd:
ldd -v /path/to/proftpd
tu devrais voir apparaître les "dépendances" comme
par exemple avec bash, chez moi ça donne:
ldd -v /bin/bash
linux-gate.so.1 => (0x00c8b000)
libtinfo.so.5 => /lib/libtinfo.so.5 (0x05a49000)
libdl.so.2 => /lib/libdl.so.2 (0x008a4000)
libc.so.6 => /lib/libc.so.6 (0x0074e000)
/lib/ld-linux.so.2 (0x00309000)
Version information:
/bin/bash:
libdl.so.2 (GLIBC_2.1) => /lib/libdl.so.2
libdl.so.2 (GLIBC_2.0) => /lib/libdl.so.2
libc.so.6 (GLIBC_2.4) => /lib/libc.so.6
libc.so.6 (GLIBC_2.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.2) => /lib/libc.so.6
libc.so.6 (GLIBC_2.3.4) => /lib/libc.so.6
libc.so.6 (GLIBC_2.1) => /lib/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
/lib/libtinfo.so.5:
libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.4) => /lib/libc.so.6
libc.so.6 (GLIBC_2.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.2) => /lib/libc.so.6
libc.so.6 (GLIBC_2.3.4) => /lib/libc.so.6
libc.so.6 (GLIBC_2.1) => /lib/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
/lib/libdl.so.2:
ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2
libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.1) => /lib/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
libc.so.6 (GLIBC_PRIVATE) => /lib/libc.so.6
/lib/libc.so.6:
ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.3) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2
Tu peux aussi comparer la sortie de
ldd -v /bin/bash
sur ta machine créant des RPMs moisis avec celle qui fonctionne.
--
Erk
_______________________________________________
Toulouse-ll mailing list
Toulouse-ll@toulibre.org
http://toulibre.org/cgi-bin/mailman/listinfo/toulouse-ll
