Bonjour,

J'ai un soft qui DOIT tourner sur une RHEL 4, qui a été installé dessus, mais après bougé (soigneusement) vers une SLES11

Les permissions, emplacements, liens mous,etc... ont été bougé avec soin.

Le bazard (graphique) se lance bien et, après les premières heures de tests il semble même qu'on ait un truc stable.

Seul hic qui fait pas sérieux: il y a une lib *.so qui crache des petits erreurs...


J'insiste bien sur le fait que "nomDeLaLib.so" est une librairie _DU_ soft bougé et non pas de l'envirronement (distro)

Je comprends cela comme si cette librairie référençait un objet dans une autre librairie (de l'OS SLES11 cette fois?) forcément pas la même (version?) que sur la RHEL4 et que donc cela merde.
Correct ?


Question, alors: comment remonter la cascade d'appels vers cet objet/librairieDeL'OS ?
ldd est-il mon ami ici? strace?

Et si je trouve la librairie qui merde, puis-je bêtement la bouger vers la nouvelle machine?

Bon...
mes amis sont donc:
$~# readelf -d ./lebinaire
$~# ldd -dr ./lebinaire
$~# nm -C ./lebinaire
$~# nm ./lebinaire
$~# /sbin/lddconf

Je pense que je peux isoler un problème sur :

$~# ldd -dr ./lebinaire
libexpat.so.1 => /lib/libexpat.so.1 (0xb68d5000)
undefined symbol: __symbola (/chemin/du/soft/porté/nomDeLaLib.so)
undefined symbol: __symbolb (/chemin/du/soft/porté/nomDeLaLib.so)
undefined symbol: __symbolc (/chemin/du/soft/porté/nomDeLaLib.so)
undefined symbol: __symbold (/chemin/du/soft/porté/nomDeLaLib.so)

Seul hic: ce libexpat.so* est introuvable sur la RHEL4

Je suppose que le binaire n'a pas été compilé sur la machine ou tu testes ...

Je voudrais bien essayer de répondre, mais ta question manque de structure, et je n'arrive pas à avoir une image claire de la situation.

Peux-tu préciser:
- La RHEL4 est bien la machine sur laquelle tout marche et dont vous avec copié des fichiers vers une SLES11 où tu as des erreur toutes les minutes ?
- le résultat du ldd est sur la RHEL4 ?
- quels fichiers ont été copiés ?
- quel est le résultat du ldd sur la machine SLES11 ?

rfr> je précise que rien n'a jamais été compilé par mes/nos soins: ni sous RHEL ni sous
SLES11... on parle d'un vrai install-binaire-crasse-proprio. exigeant une RHEL (ou du solaris ou windows server...bref qqchose qui "s'achète")


Ta lumière m'intéresse, je vais faire un effort de clareté...


C'est correct, exactement cela.

Non, tous les print que je fais sont sur la SLES1

Très exactement tout ce qui a été installé par le setup-proprio-crasse.
Y compris les liens-mous vers les rc3.d et les init.d, histoire d'avoir les bons Xevents (c'était un oubli à la base, et on avait des couleurs degueux...)
Pour le reste, je dois avouer que c'est hyper bien condensé dans /etc/opt/, /opt, /var/opt et /usr/ sans se répandre partout.


Ceux affichés plus haut.


Mais c'est justement en pensant comme toi (comparaisons de ldd sous RHEL _et_ sous SLES) que m'est venu la vision de la flexibilité du choix des *.so (dieu que c'est puissant) et je vois bien que sous SLES il utilise un libexpat.so.1 de merde (rajouté à la main par mes soins pour faire marcher wxPython (qui marche)) et sur la RHEL le fichier libexpat.so n'existe même pas....

Le ldd dit tout de même qu'il est en /lib/libexpat.so.1 non ? Il l'invente pas celui-là, il y trouve même l'adresse de la référence au symbole non trouvé. Si ?

C'est bien ce qu'il dit ... il ne trouve pas le libexpat.so.1 sur la RHEL mais il se trouve sur la SLES11 (j'avoue que je viens juste de comprendre ...)

Note que s'il tape un ldd sur la RHEL4, il y aurait matière à comparer.

Je crois en effet que cette matière à comparer va me donner la solution...
donc voici:


Ma discretion (remplacement de noms) jusqu'ici était pour m'éviter les foudres de HP (et donc Zion?) mais bon voilà, je pense que les références réèles sont plus parlantes.

(Zion, s'il y a un truc à faire en plus pour que mes liens ne soient pas googlables, feel free! Ah oui, et p-ê que HP s'en tape et contre-tape.... )



Zoé: ah oui, et un petit test sur la SLES11: j'ai voulu virer (déplacer en réalité) les méchante libexpat.so* et ses liens mous qui posaient problème, j'ai relancé ldconfig (tjrs content...) mais...le binaire continue de buter dessus ?!?!

http://www.ntg.nl/pipermail/ntg-vtex/2003-September/000367.html

Il semblerait qu'il faille downgrader libstdc++

Aaahhhhh!

Intéressant...j'avais lu un truc du genre, mais je pige pas le cheminement du raisonement: dans les deux outputs de ldd, la ligne libstdc++ est la même et ne semble pas poser de soucis, si?

Et, for the sake of it, juste pour tester, tu ferais comment pour utiliser une version plus vieille?
je me démerde pour chopper une bonne vieille *so qui traine?
j'ajoute un rpn à la main?
(encore une fois, je n'ai pas le loisir de recompiler le binaire pour le "forcer" à utiliser une lib plutôt qu'une autre...cela va se faire tout seul?)

Ça, tu peux le faire avec LD_PRELOAD.

En effet ,tant que tu payes la licence, ils s'en tapent que tu installes openview sur la machine à café du bureau
En cas de problèmes , le helpdesk te répondra que la configuration n'est pas supportée et qu'ils ne peuvent rien faire pour toi

Dan> c'est noté.
Phil> mmh intéressant! Il me reste à trouver une libstdc++ antérieure et la taper dans cette var?


Sur la SLES11, j'ai :

Essayons:
$~# export LD_PRELOAD=/usr/lib/libstdc++.so.5.0.7 && /chemin/vers/mon/binaire
me donne tjrs le undefined symbol...

J'ai tenté aussi de bouger le softlink comme suit:

rwxrwxrwx 1 root root 18 Jan 24 15:00 libstdc++-libc6.2-2.so.3 -> libstdc++.so.5.0.7
lrwxrwxrwx 1 root root 18 Jan 24 14:59 libstdc++.so.5 -> libstdc++.so.5.0.7
-rwxr-xr-x 1 root root 732K Feb 21 2009 libstdc++.so.5.0.7
lrwxrwxrwx 1 root root 19 Jan 24 14:40 libstdc++.so.6 -> libstdc++.so.6.0.10
-rwxr-xr-x 1 root root 945K May 5 2010 libstdc++.so.6.0.10

(avant libstdc++-libc6.2-2.so.3 pointait vers libstdc++.so.6)

Mais pas mieux...

Cela commence à prendre forme.

Encore une petite question *bonus* :

De manière générale, est-ce qu'on peut dire qu'une librairie *.so et sa version soient étroitement lié à la version d'un kernel et/ou à la version d'une distribution?

"ballader" des version de librairies est-donc dégueulasse si on ne respecte pas bien des dépendances, cela je peux comprendre, mais est-ce fortement dégueulasse de les passer d'un kernel à l'autre?


on parlerait d'une librairie développée/compilée pour un kernel donné?!

Ou bien on peut parler de (backward)-compatibilité ?

Pas de souci pour le kernel. La compatibilité des system calls est la seule respectée par Linus.

Merci.