Bonjour à tous!
 
Je suis face à un problème très délicat: je n'arrive pas à upgrader Perl sur Linux.
 
Quand j'upgrade Perl avec un RPM, j'obtient systématiquement une erreur sur tous les scripts perl, de type:
<<Ne peut trouver ``tel package`` dans @INC>>.
 
J'aurais besoin de conseils pour régler ce problème sans avoir à mettre mon système HS trop longtemps.
 
Comment puis-je bricoler le @INC, ou le réparer?
 
perl -V:

tree -L 1 /usr/lib/perl5/:

Merci par avance pour votre aide

et comment est ce que tu mets à jour perl ?

avec urpmi...?

J'ai plein de programmes sur mon système qui dépendent du package Perl, y compris le serveur apache que je ne désirerai pas éteindre trop longtemps.
 
Quand j'essaye d'upgrader avec un RPM c'est la panique, le sytème est totalement H.S.: plus de serveur X, plus de serveur web, tous les scripts Mandrake plantent...
 
Pour passer des version 5.8.3 à la version 5.8.5 j'ai dû bricoler le @INC, mais je ne me souviens plus du tout comment j'ai fait. Alors j'ai laissé tomber pour la version 3.8.6 (bonne galère aussi pour retourner une version en arrière!): Perl se mettait soit à mélanger les packages des trois versions, soit à ignorer les nouveaux packages.
 
Maintenant je suis coincé, j'ai besoin d'upgrader beaucoup trop de programmes pour tous les compiler à la main, et j'aurai aimé avoir la dernière version de Perl aussi.

Tu peux retrouver ton @INC d'origine en faisant :  (dans un script perl)

 
Rajouter des répertoires dans @INC :  

 
Ou alors exécute :  

heu, ouais, ça jai essayé, mais comme je suis sous mandrake et qu elle utilise plein de scripts perl, pleins de trucs se mettent à planter - je ne peut pas changer tous les scripts système.
 
sinon j ai essayé de modifier les variables d environnement  $PERL5LIB et $PERLLIB, mais ça buggue encore plus puisqu il se met alors à mélanger les différentes versions de perl...
 
bref, je suis coincé si je ne trouve où se trouve la définition de ce fameux ORIG_INC (que je ne conaissait pas, je vais chercher si je le trouve pas qqpart)...

pas de ORIG_INC que je peut changer (définit dans /usr/lib/perl5/5.8.5/i386-linux-thread-multi/lib.pm comme copie de @INC)
 
Pas de @INC définit dans un fichier de config quelquonque..
 
à l'aide! :|

ahhhhh, donc tu essaies d'installer une version de perl non prévue pour ta distro ....
 
La Mandriva 2006.0 a perl 5.8.7. tu as plus vite fait de faire une mise à jour avec le CD vers la mandriva 2006.0

j'ai de base mandrake 10.0
tu veux dire que je doit réinstaller mons ystème avec mandriva?

c'est chaud :S
j'ai plein de drivers, un kernel, et plein de programmes compilés-maison... je réalise pas la portée d'une réinstalle.. c'est chaud chaud chaud/
 
NB: pour l'instant je me suis contenté d'upgrades

Bon, il me reste plus qu a installer une mandriva
 
Merci aux participants

lors de l'installation, tu peux sélectionner mises à jour, cela fera une mise à jour des programmes.
 
sinon faire une upgrade de mandriva 10.0 vers 2006.0 est problématique en ligne de commande avec urpmi. je me suis cassé les dents dessus plusieurs fois : http://www.linux-wizard.net/index.php?id_blog=43

> lors de l'installation, tu peux sélectionner mises à jour, cela fera une mise à jour des programmes.
- ouais, ok, mais pour mon système, hybride compilé/rpms/urpmi, ça veux dire install des trucs que j'ai compilé (c'est pour ça que je disais chaud chaud chaud!)
 
> sinon faire une upgrade de mandriva 10.0 vers 2006.0 est problématique en ligne de commande avec urpmi.
- j'en ai bien l'impression
 
Je vous tient au courant du déroulement mais je vais pas faire ça tout de suite.

Sur les conseils d'un experl (un expert en perl), réinstalle de perl, <<cool, c'est bon, perl c'est trop de la balle, blabla blabla>>
 
Résultat: système down pendant les 10 prochaines heures, le temps de télécharger un DVD mandriva.
 
Le prochain qui me dit <<perl c'est trop de la balle>> je le #%&@$#*!

ho ouais
je viens de retourver X11
Mandriva m'a fait planter tout ce qu'il pouvait: apache, mysql, la procédure de démarrage, X11, le kernel, php, xfs, et j'ai pas encore fait le tour...

Pour php, un upgrade supplémentaire résoud la plupart des problèmes, reste qu'il m'a viré le fichier de conf, aussi il faut refaire le php.ini.
 
Ensuite, Apache démarre.
 
Pour mysql, c'était l'option MYSQLD_OPTIONS="--skip-networking" à commenter dans /etc/sysconfig/mysqld et à remplacer par bind-address=127.0.0.1 dans /etc/my.cnf, sinon impossible de redémarrer le service mysqld, et plantage avec PHP. Du coup, portage de toutes les requêtes mysql_connect qui utilisent "127.0.0.1" avec PHP vers "localhost".
 
Pour X11, upgrader, reconfigurer. Virer ou recommencer les configs perso sur les polices X11 (xfs).
 
Pour la procédure de redémarrage, Mandriva laisse plein de cochonneries dans tous les coins, retirer les liens cassés. Tester les services un à un. Telnet plante encore (libkrb4.so.2: introuvable), sauf avec xinetd (?!).
 
Comme j'avais des drivers non-standards, donc un kernel compilé maison, recompiler le noyau (plus récent que celui fourni, tant qu'à faire) et les drivers.
 
Lilo, si c'est déjà le boxon, ça l'est encore plus après le passage de Mandriva. Nettoyage, élagage, redémarrage(s).
 
Udev... ha oui udev, encore des problèmes d'incompatibilité, comme j'ai des drivers spéciaux. Il ne faut pas compter sur Mandriva pour remarquer que udev a été viré exprès. Pas encore résolu.
 
KDE, génial il m'a viré certaines configs, polices, couleurs, remise à zéro de l'accessibilité, ... et d'autres pas. Ça sera pour plus tard.
 
Globalement, le système est plus rapide. Sauf pour l'installation (3-4 heures).
 
Système presque up & running
 
Edit: ha oui, aussi, il ne faut pas compter récupérer la config de urpmi.
Edit: youpi! j'ai la télé! Postgresql n'a absolument aucun problème, comme d'hab.

disons qu'il est difficil de fonctionner sans udev désormais.
 
devfs est en train d'être retiré du noyau. si tu as besoin de liens statiques pour tes pilotes maisons, alors tu peux le faire avec udev, ils seront restaurés au démarrage.

Ouais, merci du conseil.
 
J'avais déjà essayé de configurer udev, mais c'était pas terrible, aussi j'ai abandonné. Avec la nouvelle version de udev ça doit être plus facile.
Le pilote maison qu'il me reste à configurer c'est pour une webcam, je vais d'abord vérifier si la dernière version du pilote est compatible udev.
 
Pour l'instant je me bat avec les incompatibilités entre les librairies xorg et XFree. Nouvelles librairies, nouveau compilateur, nouvelles erreurs.
 
Idem pour d'autres librairies, qt doit être upgrader à nouveau, mais il reste plein de warnings. SDL plante, sûrement à cause de xorg/XFree.
 
Aucune idée encore de ce qu'a fait Mandriva avec les différentes versions de la glibc que j'avais installé.

1. utilise xorg et vire les packages xfree restant
 
2. quelle version de Qt traine ?
 
3. tu as une ancienne version de glibc dispo pour compatibilité avec d'ancienne applis : libstdc++2.10 , libstdc++5

1. utilise xorg et vire les packages xfree restant
ok, j'essaye; normalement j'avais déjà viré tous les trucs qui utilisaient XFree, mais SDL ne link pas: il s'attend à trouver des librairies XFree apparemment, ou alors la version xorg doit être upgradé, SDL est déjà au max.
 
2. quelle version de Qt traine ?
J'ai besoin de Qt=3, ça compile après upgrade dernière 3.3.4. Mais pleins de warnings style ``desctructeur virtuel manquant``. Erreur à l'execution <<QMultiInputContext::changeInputMethod(): index=0, slave=xim>>, SegFault en mode optimisant, pas d'aide sur le web.
 
3. ok, je vais voir ce dont j'ai besoin. j'ai l'impression qu'une recompilation de mes programmes suffira.
 
Au fait, merci Dark_Schneider, tes conseils m'aident bien.

euh xorg est compatible avec xfree ...
 
pour voir ce qui est sur ton système et ce qui est dispo dans les dépôts rpms de Mandriva ( en admettant que tu as ajouté les média main, contrib, plf-free et plf-nonfree ) : http://easyurpmi.zarb.org
 

 
urpmq --list : permet de lister les rpms disponibles dans les média d'urpmi.

oui, je connaissais Easy Urpmi, c'est super comme site.
 
urpmi me fait des trucs bizarre, j'utilise la touche <tab> et il me liste tous les packages, avant il me lister que ceux à installer ou upgrader.
 
qt est: libqt3-3.3.4-7.1 mélangé avec 3.3.4-23 (c'est peut être ça le problème)
 
xorg: 6.9.0-5.3,
xorg disponible 6.9.1/cvs
 
Idem, j'ai deux sous-versions de SDL, c'est peut être ça le problème

upgrade de SDL, et c'est bon. il n'y avait pas de problème avec xorg/XFree en fait.

grosse galère avec Qt3.
J'ai homogénéisé la version installé via rpms.
Ça ne fonctionne toujours pas: plantages à l'execution de programmes compilés avec optimisations. En vresion debug, warnings de Qt:
QMultiInputContext::changeInputMethod(): index=0, slave=xim
À la compilation une tonne de warnings.
 
J'ai essayé Qt4, sans plus de succès puisque je dois changer toutes mes sources, dû à une organisation différente de la librairie.
 
J'essaye de compiler Qt3 à la main. Pour l'instant, galère d'installation et de cohabitation avec les versions RPMs.

ne compile pas Qt3 à lamain.
 
Il y a dans Qt3 de Mandriva un patch pour IM ( support entrée pour le chinois/... ). C'est peut être ce patch qui pose problème.
 
tu peux surement récupérer le src.rpm de qt et enlever le patch ou faire un rapport de bug sur http://qa.mandriva.com afin que ce problème soit corrigé.
 
et fais voir le résultat de :

oh la depuis que j'ai installé Qt4, c'est le boxon:

Note que Qt4 et Qt3 ne collisionnent pas. D'ailleurs je n'ai toujours pas réussi à compiler avec Qt4.
 
Sur le site de Qt, j'ai vu que Qt 3.3.6 était disponible, mais je ne l'ai pas touvé avec urpmi.
 
J'avais fait un programme avec Qt 3.3.4 pour un infographiste, ce qui me dérange c'est que depuis il ne compile plus, et ça me simplifierai si je pouvais garder Qt 3.3.4 pour éviter les problèmes de compatibilités.
 
Edit: j'ai ajouté des signes * (Qt4) > (Qt3) et ? (autre)

Edit: j'ai ajouté des signes * (Qt4) > (Qt3) et ? (autre)
 
Je crois que je vais carrément leur envoyer l'adresse de cette thread, à Mandriva

1. vire les packages concernant Qt4
 
2. n'utilise que les versions disponibles et utilisées sous Mandriva ! La 2006.0 utilise la version 3.3.4, donc garde celle là.
 
Pour ton problème de compilation, fais un rapport de bug sur http://qa.mandriva.com concernant qt3.
 
Note : les packages scim-qtimm/uim-qt/uim-qtimmodule/uim-qt aideront peut être pour le lanceement du programme.
 
Ne mets pas les optimisations lors de la compilation et fais un strace ou utilise gdb pour déterminer l'endroit où cela merde.

1. Ok
2. Ok
> rapport de bug
ouais...
> packages scim-qtimm/uim-qt/uim-qtimmodule/uim-qt
je vais me renseigner
> Ne mets pas les optimisations
je ne peut pas me le permettre dans la version de production: 11 Mégas sans, 600 Kilos avec optimisations...
> strace gdb
exact, seulement en version débug ça plante pas, avec optim ça fait un segfault.
En fait, j'ai testé un exemple de Qt3, ``canvas`` et ça plante aussi.
Je vais voir si je peut trouver les bonnes options de compil pour avoir à la fois du débug gdb et des optimisations.

Pour info, gdb me donne:

strace me donne une petite idée de l'origine du segfault.

bof, en essayant de débugger, j'ai mis une fonction inline qui devait planter dans un .cpp et j'ai plus de segfault. ça laisse quand même un arrière goût amer.
 
Merci encore une fois pour ton aide, Dark_Schneider

tu peux aussi essayer avec des compilation moins violentes, moins fortes ( genre -01 au lieu de -03, etc ... )

Pour ce programme j'ai besoin de -O2, au moins, à cause de la taille de l'éxécutable..
En fait je dois avoir un un bug dans mon programme, qui m'était passé entre les doigts. Au moins j'ai réussi à isoler le bug à 2 fonctions. Dès que possible je l'éradique.
Je soupçonne qu'une des fonctions de Qt (QSettings ou QColor) fonctionne mal avec QString::null.
 
En ce qui concerne tous les warnings que me donne Qt, il s'agit uniquement des destructeur virtuels manquants lors de la compilation de fichiers moc. Donc, j'ai refait les makefiles pour avoir la compilation des mocs à la fin, et pour l'instant je me débrouille avec.
 
Pour le reste du système, ça fonctionne.