[IRIX] Librairies sous UNIX

Salut,

je crois que j'ai du mal à comprendre le fonctionnement des librairies :aie:...
voilà mon souci :

je crée plusieurs librairies .a à partir de code c++ et d'autres à partie de code fortran 90
pas de soucis à la compil,
pas de soucis à l'édition de lien.

j'assemble le tout dans un .so, pas de soucis à part une floppée de warnings :
ld64: WARNING 131: Multiply defined weak symbol:(_M_acquire_lock__Q2_3std15_STL_mutex_lockGv) in /home/user/staff/...../libmini1.a(fichier1.o) and /home/user/staff/...../libmini2.a(fichier2.o) (2nd definition ignored).
à part ça, tout va bien

Mon but étant d'importer ma librairie dans du code python, je lance ma console et je tape import ma librairie :
$ python
Python 2.3.5 (#1, Sep 26 2006, 15:35:17) [C] on irix6-64
Type "help", "copyright", "credits" or "license" for more information.
>>> import grosseLibrairie
Traceback (most recent call last):
File "<stdin>", line 1, in ?
ImportError: 8304:python: rld: Fatal Error: unresolvable symbol in ./grosseLibrairie.so: afficherNomCommande

je vérifie l'existence de cette fonction avec la commande nm :
$ nm libmini3.a | grep afficherNomCommande
[23] | 128| 248|FUNC |GLOB |DEFAULT |5 |afficherNomCommande
[17] | 0| 0|FUNC |GLOB |DEFAULT |UNDEF |afficherNomCommande

et pareil dans ma librairie .so, qui est sensée contenir cette lib.a
$ nm grosseLibrairie.so | grep afficherNomCommande
[543] |3752216220| 0|FUNC |GLOB |DEFAULT |UNDEF |afficherNomCommande

Le .so n'est-il pas sensé contenir l'information?
J'ai cherché sur le net mais je galère... Si quelqu'un avait un site ou un ouvrage à me conseiller, ça serait bien sympathique.

je suis sous IRIX6.5 en 64bits, voici mes options de compil et link :
C_COMP = cc -64 -w -LANG:std
CPP_COMP = CC -64 -w -LANG:std
F77_COMP = f90 -64 -w
F90_COMP = f90 -64 -w
LD_COMP = ld -shared -64 -o
AR_COMP = ar rv
C_FLAGS = -g -DUNIX
CPP_FLAGS = $(C_FLAGS)

voici ma commande pour créer mon .so:
(j'ai un fichier cpp en plus des librairies.a pour le wrapping python)
$(LD_COMP) grosseLibrairie.so $(CPP_OBJ) -wall -L$(INSTDIR)/lib -B static -lmini3 -lmini2 -lmini1 -B dynamic -lCio ;

Je ne connais pas Irix, mais ton linker a probablement une option pour indiquer quels symboles doivent être "exportés" par ton shared object. Par exemple sous AIX c'est -bE<export_file> où <export_file> est une fichier qui liste les symboles à exporter, un par ligne. Si est symbole n'est pas exporté, tu ne peux pas l'utiliser en te linkant dynamiquement à ton shared object.

effectivement, c'était bien un problème d'export, merci

je m'en suis rendu compte hier soir... une partie du code a été fait sous visual qui m'a mis des
#ifdef __cplusplus
extern "C"
#endif
et ce symbole n'était pas déclaré dans mon makefile

je viens aussi de découvrir que l'ordre des librairies .a est importante : par exemple si la libmini1.a utilise des symboles de la libmini3.a, alors je dois mettre mon -lmini1 avant le -lmini3...

tout ceci m'amène donc des nouvelles erreurs, mais un pas a été fait en avant...

Je vais essayer de trouver un tuto complet sur les makefiles, ça a l'air bien plus complexe que ce que je pensais...
Si quelqu'un a une adresse je suis preneur ^^

j'ai toujours plein de problèmes avec mes symboles :(

Code:

---

1 2 3 4

>>> import grosseLibrairie Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: 22930:python: rld: Fatal Error: unresolvable symbol in ./grosseLibrairie.so: _M_erase__Q2_3std535_Rb_tree__pt__518_Q2_3std78basic_string__pt__58_cQ2_3std20char_traits__pt__2_cQ2_3std18allocator__pt__2_cQ2_3std115pair__pt__102_CQ2_3std78basic_string__pt__58_cQ2_3std20char_traits__pt__2_cQ2_3std18allocator__pt__2_cP10TypedValueQ2_3std145_Select1st__pt__126_Q2_3std115pair__pt__102_CQ2_3std78basic_string__pt__58_cQ2_3std20char_traits__pt__2_cQ2_3std18allocator__pt__2_cP10TypedValueQ2_3std100less__pt__88_Q2_3std78basic_string__pt__58_cQ2_3std20char_traits__pt__2_cQ2_3std18allocator__pt__2_cQ2_3std31allocator__pt__14_P10TypedValueGPQ2_3std148_Rb_tree_node__pt__126_Q2_3std115pair__pt__102_CQ2_3std78basic_string__pt__58_cQ2_3std20char_traits__pt__2_cQ2_3std18allocator__pt__2_cP10TypedValue

---

(MSC comme microsoft C :cry:)

j'ai fait des recherches de ce symbole dans les .a que j'ai assemblé pour faire grosseLibrairie.so... il n'a pas l'air d'être défini dedans

je tape cette commande dans le répertoire contenant mes librairies .a :
for i in *.a ; do echo $i; nm $i | grep M_erase__Q2 | grep -v UNDEF; done;
pas de résultats

beaucoup de résultats comme ceux-ci sans le grep -v UNDEF par contre :

Code:

---

1 2 3 4

[103] | 0| 0|FUNC |GLOB |DEFAULT |UNDEF |_M_erase__Q2_3std535_Rb_tree__pt__518_Q2_3std78basic_string__pt__58_cQ2_3std20char_traits__pt__2_cQ2_3std18allocator__pt__2_cQ2_3std115pair__pt__102_CQ2_3std78basic_string__pt__58_cQ2_3std20char_traits__pt__2_cQ2_3std18allocator__pt__2_cP10TypedValueQ2_3std145_Select1st__pt__126_Q2_3std115pair__pt__102_CQ2_3std78basic_string__pt__58_cQ2_3std20char_traits__pt__2_cQ2_3std18allocator__pt__2_cP10TypedValueQ2_3std100less__pt__88_Q2_3std78basic_string__pt__58_cQ2_3std20char_traits__pt__2_cQ2_3std18allocator__pt__2_cQ2_3std31allocator__pt__14_P10TypedValueGPQ2_3std148_Rb_tree_node__pt__126_Q2_3std115pair__pt__102_CQ2_3std78basic_string__pt__58_cQ2_3std20char_traits__pt__2_cQ2_3std18allocator__pt__2_cP10TypedValue [150] | 0| 0|NOTY |LOCL |DEFAULT |UNDEF |__CBI___M_erase__Q2_3std521_Rb_tree__pt__504_Q2_3std78basic_string__pt__58_cQ2_3std20char_traits__pt__2_cQ2_3std18allocator__pt__2_cQ2_3std110pair__pt__98_CQ2_3std78basic_string__pt__58_cQ2_3std20char_traits__pt__2_cQ2_3std18allocator__pt__2_cP7gaObjetQ2_3std140_Select1st__pt__121_Q2_3std110pair__pt__98_CQ2_3std78basic_string__pt__58_cQ2_3std20char_traits__pt__2_cQ2_3std18allocator__pt__2_cP7gaObjetQ2_3std100less__pt__88_Q2_3std78basic_string__pt__58_cQ2_3std20char_traits__pt__2_cQ2_3std18allocator__pt__2_cQ2_3std27allocator__pt__10_P7gaObjetGPQ2_3std143_Rb_tree_node__pt__121_Q2_3std110pair__pt__98_CQ2_3std78basic_string__pt__58_cQ2_3std20char_traits__pt__2_cQ2_3std18allocator__pt__2_cP7gaObjet [171] | 0| 0|NOTY |LOCL |DEFAULT |UNDEF |__TIR___M_erase__Q2_3std535_Rb_tree__pt__518_Q2_3std78basic_string__pt__58_cQ2_3std20char_traits__pt__2_cQ2_3std18allocator__pt__2_cQ2_3std115pair__pt__102_CQ2_3std78basic_string__pt__58_cQ2_3std20char_traits__pt__2_cQ2_3std18allocator__pt__2_cP10TypedValueQ2_3std145_Select1st__pt__126_Q2_3std115pair__pt__102_CQ2_3std78basic_string__pt__58_cQ2_3std20char_traits__pt__2_cQ2_3std18allocator__pt__2_cP10TypedValueQ2_3std100less__pt__88_Q2_3std78basic_string__pt__58_cQ2_3std20char_traits__pt__2_cQ2_3std18allocator__pt__2_cQ2_3std31allocator__pt__14_P10TypedValueGPQ2_3std148_Rb_tree_node__pt__126_Q2_3std115pair__pt__102_CQ2_3std78basic_string__pt__58_cQ2_3std20char_traits__pt__2_cQ2_3std18allocator__pt__2_cP10TypedValue [172] | 0| 0|NOTY |LOCL |DEFAULT |UNDEF |__CBI___M_erase__Q2_3std535_Rb_tree__pt__518_Q2_3std78basic_string__pt__58_cQ2_3std20char_traits__pt__2_cQ2_3std18allocator__pt__2_cQ2_3std115pair__pt__102_CQ2_3std78basic_string__pt__58_cQ2_3std20char_traits__pt__2_cQ2_3std18allocator__pt__2_cP10TypedValueQ2_3std145_Select1st__pt__126_Q2_3std115pair__pt__102_CQ2_3std78basic_string__pt__58_cQ2_3std20char_traits__pt__2_cQ2_3std18allocator__pt__2_cP10TypedValueQ2_3std100less__pt__88_Q2_3std78basic_string__pt__58_cQ2_3std20char_traits__pt__2_cQ2_3std18allocator__pt__2_cQ2_3std31allocator__pt__14_P10TypedValueGPQ2_3std148_Rb_tree_node__pt__126_Q2_3std115pair__pt__102_CQ2_3std78basic_string__pt__58_cQ2_3std20char_traits__pt__2_cQ2_3std18allocator__pt__2_cP10TypedValue

---

et aucun résultats dans les libs du /usr/lib

Il faut savoir que le code que j'essaie d'utiliser marche bien sous windows, mais a été développé avec visual studio. Ce code compile aussi sous irix d'ailleurs.

Les seules données pouvant être reliées avec un erase sont les map que j'utilise :

typedef std::map<string,gaObjet*> objetsMap;
typedef std::map<string,TypedValue*> resultMap;
typedef std::map <string,string> preferencesMap;

Je suis complètement à cours d'idée sur les pistes à explorer...
Est ce qu'une âme charitable pourrait m'éclairer s'il vous plait

-----------

et une autre question sur mon #include <map> :
Dans visual ça m'ouvre un fichier %visual%/VC98/include/map
qui commence par

Code:

---

1 2 3 4 5

// map standard header   #if _MSC_VER > 1000 #pragma once #endif

---

(MSC comme microsoft C :cry:)

Donc il y a fort à parier que ça ouvre un fichier différent sous un autre os
j'ai un /usr/include/CC/map.h qui inclut un stl_map.h qui semble faire l'affaire...

pourtant je déclare un std::map, c'est pas sensé être "standard" ?

merci pour la patience de ceux qui me liront