bonsoir,
j'essaie de fusionner le logiciel kaffeine.
Cependant, j'ai une erreur durant la compillation:
grep: /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libstdc++.la: No such
file or directory
et c'est bien normal car libstdc++.la se trouve dans :
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/libstdc++.la
J'ai bien tenté de faire un lien : ln -s
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/libstdc++.la
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libstdc++.la
Le problème c'est que /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4 est déjà
un lien :
lrwxrwxrwx 1 root root 41 jan 20 04:04 3.3.4 ->
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/
Voilà le problème, je crois comprendre que la "rustine" que j'ai mis en
faisant un lien de 3.3.4 vers 3.3.5 me démontre ses limites.
A priori, je dirais : # fix_libtool_files.sh 3.3.4
Merci, cela a parfaitement fonctionné Puis-je enlever le lien :lrwxrwxrwx 1 root root 41 jan 20 04:04 3.3.4 -> /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/ ?
pourrais-tu m'expliquer très brièvement (dans l'attente du temps nécessaire pour lire la doc) à quoi tout ceci correspond ?
Amicalement, Olivier
-- mailing list
Thomas de Grenier de Latour
On Wed, 13 Apr 2005 00:51:39 +0200 Olinux wrote:
Puis-je enlever le lien :lrwxrwxrwx 1 root root 41 jan 20 04:04 3.3.4 ->/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/ ?
Oui, il n'y a pas de raison d'avoir un tel lien. Ça ressemble plutôt à un reste d'une précédente bidouille manuelle faite à l'occasion d'un upgrade 3.3.4->3.3.5, ou un tuc du genre.
pourrais-tu m'expliquer très brièvement (dans l'attente du temps nécessaire pour lire la doc) à quoi tout ceci correspond ?
Si tu fais par exemple un `grep /usr/lib/gcc-lib /usr/lib/*.la`, tu devrais voir que dans qlqs fichiers "*.la" (utilisés par libtool pour le linking) il y a des paths absolus vers la lib c++ de gcc. Quand on bouge cette lib, genre en mettant à jour gcc, ces fichiers ne sont donc plus corrects...
Un `fix_libtool_files.sh<vieille_version>` va donc servir à les corriger, avec le path de ton nouveau gcc. Bien sûr, en théorie les ebuilds de gcc devraient s'occuper de cette opération. Mais en pratique, ça s'avère ne pas fonctionner à tous les coups (et là, je ne détaillerai pas, parceque j'avoue qu'il y a dans gcc-config et toolchain.eclass des subtilités qui m'échappent...), donc souvent en remettre une petite couche à la main ne fait pas de mal.
-- TGL.
-- mailing list
On Wed, 13 Apr 2005 00:51:39 +0200
Olinux <humbert.olivier.1@free.fr> wrote:
Puis-je enlever le lien :lrwxrwxrwx 1 root root 41 jan 20 04:04
3.3.4 ->/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/ ?
Oui, il n'y a pas de raison d'avoir un tel lien. Ça ressemble
plutôt à un reste d'une précédente bidouille manuelle faite à
l'occasion d'un upgrade 3.3.4->3.3.5, ou un tuc du genre.
pourrais-tu m'expliquer très brièvement (dans l'attente du temps
nécessaire pour lire la doc) à quoi tout ceci correspond ?
Si tu fais par exemple un `grep /usr/lib/gcc-lib /usr/lib/*.la`,
tu devrais voir que dans qlqs fichiers "*.la" (utilisés par
libtool pour le linking) il y a des paths absolus vers la lib c++
de gcc. Quand on bouge cette lib, genre en mettant à jour gcc,
ces fichiers ne sont donc plus corrects...
Un `fix_libtool_files.sh<vieille_version>` va donc servir à les
corriger, avec le path de ton nouveau gcc. Bien sûr, en théorie
les ebuilds de gcc devraient s'occuper de cette opération. Mais en
pratique, ça s'avère ne pas fonctionner à tous les coups (et là,
je ne détaillerai pas, parceque j'avoue qu'il y a dans gcc-config
et toolchain.eclass des subtilités qui m'échappent...), donc
souvent en remettre une petite couche à la main ne fait pas de
mal.
Puis-je enlever le lien :lrwxrwxrwx 1 root root 41 jan 20 04:04 3.3.4 ->/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/ ?
Oui, il n'y a pas de raison d'avoir un tel lien. Ça ressemble plutôt à un reste d'une précédente bidouille manuelle faite à l'occasion d'un upgrade 3.3.4->3.3.5, ou un tuc du genre.
pourrais-tu m'expliquer très brièvement (dans l'attente du temps nécessaire pour lire la doc) à quoi tout ceci correspond ?
Si tu fais par exemple un `grep /usr/lib/gcc-lib /usr/lib/*.la`, tu devrais voir que dans qlqs fichiers "*.la" (utilisés par libtool pour le linking) il y a des paths absolus vers la lib c++ de gcc. Quand on bouge cette lib, genre en mettant à jour gcc, ces fichiers ne sont donc plus corrects...
Un `fix_libtool_files.sh<vieille_version>` va donc servir à les corriger, avec le path de ton nouveau gcc. Bien sûr, en théorie les ebuilds de gcc devraient s'occuper de cette opération. Mais en pratique, ça s'avère ne pas fonctionner à tous les coups (et là, je ne détaillerai pas, parceque j'avoue qu'il y a dans gcc-config et toolchain.eclass des subtilités qui m'échappent...), donc souvent en remettre une petite couche à la main ne fait pas de mal.
-- TGL.
-- mailing list
Olinux
Thomas de Grenier de Latour a écrit :
Puis-je enlever le lien :lrwxrwxrwx 1 root root 41 jan 20 04:04 3.3.4 ->/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/ ?
Oui, il n'y a pas de raison d'avoir un tel lien. Ça ressemble plutôt à un reste d'une précédente bidouille manuelle faite à l'occasion d'un upgrade 3.3.4->3.3.5, ou un tuc du genre.
oups ... je suis démasqué ... ;)
pourrais-tu m'expliquer très brièvement (dans l'attente du temps nécessaire pour lire la doc) à quoi tout ceci correspond ?
Si tu fais par exemple un `grep /usr/lib/gcc-lib /usr/lib/*.la`, tu devrais voir que dans qlqs fichiers "*.la" (utilisés par libtool pour le linking) il y a des paths absolus vers la lib c++ de gcc. Quand on bouge cette lib, genre en mettant à jour gcc, ces fichiers ne sont donc plus corrects...
en te lisant, je m'apercois que j'ai encore beaucoup dedocs à lire... <fleur color=bleue> cela s'arretera-t'il un jour??? </fleur color=bleue>
Un `fix_libtool_files.sh<vieille_version>` va donc servir à les corriger, avec le path de ton nouveau gcc. Bien sûr, en théorie les ebuilds de gcc devraient s'occuper de cette opération. Mais en pratique, ça s'avère ne pas fonctionner à tous les coups (et là, je ne détaillerai pas, parceque j'avoue qu'il y a dans gcc-config et toolchain.eclass des subtilités qui m'échappent...), donc souvent en remettre une petite couche à la main ne fait pas de mal.
merci pour ces explications Amicalement, Olivier
-- mailing list
Thomas de Grenier de Latour a écrit :
Puis-je enlever le lien :lrwxrwxrwx 1 root root 41 jan 20 04:04
3.3.4 ->/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/ ?
Oui, il n'y a pas de raison d'avoir un tel lien. Ça ressemble
plutôt à un reste d'une précédente bidouille manuelle faite à
l'occasion d'un upgrade 3.3.4->3.3.5, ou un tuc du genre.
oups ...
je suis démasqué ... ;)
pourrais-tu m'expliquer très brièvement (dans l'attente du temps
nécessaire pour lire la doc) à quoi tout ceci correspond ?
Si tu fais par exemple un `grep /usr/lib/gcc-lib /usr/lib/*.la`,
tu devrais voir que dans qlqs fichiers "*.la" (utilisés par
libtool pour le linking) il y a des paths absolus vers la lib c++
de gcc. Quand on bouge cette lib, genre en mettant à jour gcc,
ces fichiers ne sont donc plus corrects...
en te lisant, je m'apercois que j'ai encore beaucoup dedocs à lire...
<fleur color=bleue>
cela s'arretera-t'il un jour???
</fleur color=bleue>
Un `fix_libtool_files.sh<vieille_version>` va donc servir à les
corriger, avec le path de ton nouveau gcc. Bien sûr, en théorie
les ebuilds de gcc devraient s'occuper de cette opération. Mais en
pratique, ça s'avère ne pas fonctionner à tous les coups (et là,
je ne détaillerai pas, parceque j'avoue qu'il y a dans gcc-config
et toolchain.eclass des subtilités qui m'échappent...), donc
souvent en remettre une petite couche à la main ne fait pas de
mal.
Puis-je enlever le lien :lrwxrwxrwx 1 root root 41 jan 20 04:04 3.3.4 ->/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/ ?
Oui, il n'y a pas de raison d'avoir un tel lien. Ça ressemble plutôt à un reste d'une précédente bidouille manuelle faite à l'occasion d'un upgrade 3.3.4->3.3.5, ou un tuc du genre.
oups ... je suis démasqué ... ;)
pourrais-tu m'expliquer très brièvement (dans l'attente du temps nécessaire pour lire la doc) à quoi tout ceci correspond ?
Si tu fais par exemple un `grep /usr/lib/gcc-lib /usr/lib/*.la`, tu devrais voir que dans qlqs fichiers "*.la" (utilisés par libtool pour le linking) il y a des paths absolus vers la lib c++ de gcc. Quand on bouge cette lib, genre en mettant à jour gcc, ces fichiers ne sont donc plus corrects...
en te lisant, je m'apercois que j'ai encore beaucoup dedocs à lire... <fleur color=bleue> cela s'arretera-t'il un jour??? </fleur color=bleue>
Un `fix_libtool_files.sh<vieille_version>` va donc servir à les corriger, avec le path de ton nouveau gcc. Bien sûr, en théorie les ebuilds de gcc devraient s'occuper de cette opération. Mais en pratique, ça s'avère ne pas fonctionner à tous les coups (et là, je ne détaillerai pas, parceque j'avoue qu'il y a dans gcc-config et toolchain.eclass des subtilités qui m'échappent...), donc souvent en remettre une petite couche à la main ne fait pas de mal.
