Je suis une quiche en édition des liens, j'aurais besoin de votre aide...
 
J'ai une appli graphique qui fonctionne bien. Certaines fonctions sont wrappées en python pour pouvoir piloter l'appli depuis un script python. Lors de l'exécution depuis python j'ai un message d'erreur, patapay c'est sous Sun:
pyQVUI est mon interface avec mon appli.
 
 
  >>>>python screenSave.py  
Traceback (most recent call last):
  File "screenSave.py", line 10, in ?
    from pyQVUI import *
  File "/home/st14972/dev/dev_SunOS5.8_64/lib/python/pyQVUI.py", line 5, in ?
    import _pyQVUI
ImportError: ld.so.1: python: fatal: relocation error: file /home/st14972/dev/dev_SunOS5.8_64/lib/_pyQVUI.so: symbol __1cDstdNbasic_istream4Ccn0ALchar_traits4Cc___Funget6M_r1_: referenced symbol not found
 
 
 
 
ldd de _pyQVUI.so :
 

 
 
Où est-ce que je peux trouver le symbole manquant (__1cDstdNbasic_istream4Ccn0ALchar_traits4Cc___Funget6M_r1_)?  
 
J'utilise aCC pour compiler. (patapay)

up

J'ai vu que mon post a été déplacé dans la catégorie python, pas de souci.
 
Je veux juste souligner que bien que je parle de wrapping python les développeurs C peuvent surement m'aider car avec le code C généré par swig je crée une lib dynamique avec mon compilateur C, et le import depuis python révèle juste un problème avec le ld, j'ai donc mal fait mon link après la compilation.

problème de version d'ABI.
Fait un nm /path/to/lib et grep dedans ton symbole manquant.
Après avec nm -C tu peux le dé-mangler pour savoir à quoi ça correspond comme fonction.
 
Est-ce que cette lib elle est à toi, genre style c'est toi qui l'a compilé ?

c'est du C++ ce code

J'y connais rien en Python, mais si y'a du C++ derrière, je te conseillerais de regarder les includes dans les fichiers sources.
 
Genre #include <string>, #include <iostream>...
 
Si tu trouves du #include "string.h" par exemple, essaye de le remplacer par un <string>
 
Après là comme ça, je peux pas vraiment t'aider, en voyant __1cDstdNbasic_istream4Ccn0ALchar_traits4Cc___Funget6M_r1_, on a l'impression qu'il manque la librairie istream, qui devrait être linkée automatiquement quand tu fais un #include <istream> (ou iostream) dans ton code...

c'est un peu comme si je faisais une prière et que Dieu mettait un dans ma prière  
D'ailleurs avant de me coucher hier j'ai pensé à demangle, un MP de Dieu probablement.  
Je sais que c'est du C++, mais ça faisait deux caractère à écrire en plus
 
Comment tu sais que c'est un problème d'ABI? Est-ce que ça veut dire qu'une lib va chercher du 32bits au lieu de 64?  
 
Est-ce que choisir Abby c'est un hasard?

Oops, j'ai lu en diagonale.

Je remets dans C++.

 
 
Ca compile sans problème, je cherche effectivement la lib qui contient mon symbole not found

 
 
c'est bien moi qui l'ai compilée au fait.
 

le -C marche pas, ni --demangle, j'échoue
nm -C /home/st14972/dev/dev_SunOS5.8_64/lib/_pyQVUI.so | grep unget
                 U __1cDstdNbasic_istream4Ccn0ALchar_traits4Cc___Funget6M_r1_

T'es sous Sun, c'est ça ?
Regarde si t'as pas un nm sous /usr/xpg4/bin ou /usr/ccs/bin, c'est pas le même que par défaut et il prend l'option -C celui-là.

 
 
Merci,
 
/usr/ccs/bin/nm -C /home/st14972/dev/dev_SunOS5.8_64/lib/_pyQVUI.so | grep unget  
[11104] |             0|           0|FUNC |GLOB |0    |UNDEF  |std::basic_istream<char,std::char_traits<char> >&std::basic_istream<char,std::char_traits<char> >::unget()
                                                       [__1cDstdNbasic_istream4Ccn0ALchar_traits4Cc___Funget6M_r1_]
 
 
effectivement mon PATH est pollué par un pack gcc qui amène des lib et des outils à la con. Mais je crois qu'il est nécessaire pour l'utilisation du python que je dois utiliser. Je vais essayer de le virer de mon environnent.  

C'est Abby NCIS.

je capte pas d'où vient cette méthode unget(), si seulement j'arrivais à trouver où je l'appelle...

elle sort probablement d'une méthode template ou inlinée si ça vient pas de toi.

elle est pas dans ma version linux ça aussi je capte pas
 
Sinon elle est defined dans le nm du binaire de mon appli :
 
python : import _pyQVUI
_pyQVUI.so (interface de wrapping avec l'appli) -> unget Undefined
appli -> unget Defined
 
Le symbole devrait pas être résolu à l'import?

bah si c'est ce qui se passe, sauf que ça trouve pas. A part comparer les lib utilisées, je vois pas trop. Dans ton appli, le symbole est à résoudre ou bien il est défini ?
 
acc c'est bien, mais est-ce que ça a la même ABI que gcc ? (vu que tu pull libgcc)

dans l'appli il est à résoudre, même il est pas pas utilisé, j'ai fait des grep unget partout et je trouve rien, j'ai même pas de ifstream...  
 
je sais pas comment on vérifie le type? version? d'ABI, je sais juste que la variable d'environnement ABI=64 quand on st en 64 bits et pas définie quand on est en 32.

Très fatigué, mais en passant et en lecture diagonale, si je dis pas trop de conneries:

Ca fait quelque temps que j'ai pas joué à faire des libs python, mais est-ce qu'il ne chercherait à résoudre certains symboles, même s'ils ne sont jamais appelés, lors de l'import?

Est-ce que tu peux donner les headers de ta lib et de ton appli? Genre objdump -p?

Je te donne ça demain, quand je pourrai passer le firewall de Saint-Martin

t'as un gnuld ou pas ? (--as-needed)

si tu rajoutes un main à ton wrapper, il s'exécute ok ?

( http://udrepper.livejournal.com/8790.html article sympa sur comment faire des bonnes tartes)

 
 
un peu endormi hier soir, dans l'appli le symbole est défini, mais pas dans le wrapper

si dans l'appli t'arrives à localiser dans quelle unité de compilation il est défini, ça pourrait te tuyauter un peu, non ?
 
tu fais des nm sur .o et tu cherches

j'ai trouvé qu'en fait c'est une fucking lib à laquelle je me link statiquement mais avec un -lfukinglib donc je croyais que j'avais que des lib dynamiques. Le problème serait donc que cette lib a été compilée avec un compilo différent du mien et que cette méthode unget est obsolète par exemple?

question bête: y'a pas moyen de demander à python de pas chercher à résoudre tous les symboles à l'import de mon module wrappé?