Étrange cas de symbol lookup error

Bonjour à tous

Je suis en train de développer une application. Dans cette application, j'ai besoin de faire appel à un moteur de résolution de problème. Afin que mon appli soit plus ou moins indépendante du moteur, j'ai défini une interface (via un Moteur.h) de moteur et je link avec une librairie libmoteur.so
Pour que ce moteur puisse être utilisé par mon appli, il leur faut donc me fournir un 'libmoteur.so' qui implémente Monteur.h.

J'ai pris un de ces moteurs, j'ai modifié un peu le code pour faire la librairie dont j'ai besoin. Ensuite, pour que ce moteur puisse mieux s'intégrer à mon appli, j'utilise des méthodes définies dans mon appli.

Je compile ma librairie, ensuite je compile mon appli en donnant bien à gcc -lmoteur

Ensuite, j'exécute mon binaire, en prenant bien soins que libmoteur.so soit dans mon LD_LIBRARY_PATH et là, j'obtient l'erreur suivante à l'exécution:

./mon_appli: symbol lookup error: ./chemin/libsolver.so: undefined symbol: _ZN6appli6ObjetAppli7maMethodeEv


J'ai fait quelques recherches, et je me suis rendu compte que parmi les symboles de mon appli utilisés par ma librairie (13), il y en a deux qui ne sont pas trouvés

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

$ LD_LIBRARY_PATH=./chemin/:$LD_LIBRARY_PATH ldd -d -r ./mon_appli linux-vdso.so.1 => (0x00007fffe78ff000) libpthread.so.0 => /lib64/libpthread.so.0 (0x000000349de00000) libmoteur.so => ./chemin/libmoteur.so (0x00007f26f9f15000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00000034a4200000) libm.so.6 => /lib64/libm.so.6 (0x000000349d600000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000034a2200000) libc.so.6 => /lib64/libc.so.6 (0x000000349d200000) /lib64/ld-linux-x86-64.so.2 (0x000000349ce00000) libz.so.1 => /lib64/libz.so.1 (0x000000349e200000) undefined symbol: _ZN6appli6ObjetAppli9maMethodeEv (./chemin/libmoteur.so) undefined symbol: _ZN6appli6ObjetAppli7autreMethodeEv (./chemin/libmoteur.so)   $ ldd -d -r ./chemin/libmoteur.so linux-vdso.so.1 => (0x00007fff7af50000) libz.so.1 => /lib64/libz.so.1 (0x00007f8703773000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f870346d000) libm.so.6 => /lib64/libm.so.6 (0x00007f87031e8000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f8702fd2000) libc.so.6 => /lib64/libc.so.6 (0x00007f8702c3f000) /lib64/ld-linux-x86-64.so.2 (0x000000349ce00000) undefined symbol: _ZTIN6appli6UnObjetE (./chemin/libmoteur.so) undefined symbol: _ZN6appli6AutreObjet4astaticFieldE (./chemin/libmoteur.so) undefined symbol: _ZN6appli6ObjetAppli9maMethodeEv (./chemin/libmoteur.so) undefined symbol: _ZN6appli9DernierObjet6signalEv (./chemin/libmoteur.so) undefined symbol: _ZN6appli6ObjetAppli22methoderssEv (./chemin/libmoteur.so) undefined symbol: _ZN6appli9DernierObjet4methodewEv (./chemin/libmoteur.so) undefined symbol: _ZlsRN6appli6AutreObjetEPKc (./chemin/libmoteur.so) undefined symbol: _ZN6appli6ObjetAppli7autreMethodeEv (./chemin/libmoteur.so) undefined symbol: _ZlsRN6appli6AutreObjetEd (./chemin/libmoteur.so) undefined symbol: _ZN6appli6UnObjetC2Ev (./chemin/libmoteur.so) undefined symbol: _ZN6appli6UnObjetD2Ev (./chemin/libmoteur.so) undefined symbol: _ZlsRN6appli6AutreObjetEi (./chemin/libmoteur.so) undefined symbol: _ZlsRN6appli6AutreObjetERNS0_15AutreObjetSousObjet (./chemin/libmoteur.so)

---

Du coup, je trouve ça un peu bizarre qu'il n'y a que deux (et pas 0 ou 13) undefined symbol.

Est-ce que quelqu'un à une idée?

Même version de compilo et options de compil partout?
Même version du header dans les deux cas?
J'imagine que tu reconnais les méthodes concernées, elles n'ont pas évolué depuis?

Même version du compilateur:
g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3)

C'est la même version du header. J'ai fait un test en modifiant le nom d'une méthode dans le .h, et après j'ai tenté de recompilé mon appli, mais il y a eu une erreur => l'appli prend bien en compte le .h que je veux, et pareil pour le moteur

Il y a eu de l'évolution, mais j'ai recompilé les deux.

D'ailleurs, si je regarde les symboles définis dans mon binaire, je trouve bien:

Code:

---

1 2 3 4 5

$ nm mon_appli | grep "_ZN6appli6ObjetAppli9maMethodeEv" 00000000004166c0 T _ZN6appli6ObjetAppli9maMethodeEv   nm mon_appli | grep "_ZN6appli6ObjetAppli7autreMethodeEv" 0000000000416710 T _ZN6appli6ObjetAppli7autreMethodeEv

---

Ce qui est étrange c'est qu'un des marqueurs (je ne sais pas par cœur lequel, il me semble que c'est le "T") signifie un symbole qui est utilisé par le binaire, mais défini par un autre module.
Donc les deux modules ne devraient pas avoir la même ligne pour le symbole...c'est du call back? Où est la définition de la méthode en question?
EDIT: à oublier, j'avais lu trop vite et cru voir nm dans le main et nm dans la lib :aie:

D'après ceci le "T" signifie que les deux binaires définissent le symbole.
Ça provoque peut-être un conflit qui bloque le link?

Oups autant pour moi je me suis emballé :oops:.
Tu as regardé comment le symbole apparaît au niveau de ta lib?

Au niveau de ma lib, les symboles apparaissent de la manière suivante:

Code:

---

1 2 3 4 5

nm ./chemin/libmoteur.so | grep "_ZN6appli6ObjetAppli9maMethodeEv" U _ZN6appli6ObjetAppli9maMethodeEv   nm ./chemin/libmoteur.so | grep "_ZN6appli6ObjetAppli7autreMethodeEv" U _ZN6appli6ObjetAppli7autreMethodeEv

---

Autre bizarrerie, lorsque je lance l'appli, elle s'exécute un peu puis plante. Comme si des symboles étaient recherchés au moment de leur appel...

Y'aurait pas un ./chemin/appli sans ces deux symboles qui traîne par hasard?

1/ Voir -fpie/-fPIE qui est pour les executables ce que -fpic/-fPIC est pour les libs

2/ C'est normal de n'avoir l'erreur que quand on cherche le symbole. Utilise la variable d'environnement LD_BIND_NOW faire toutes les recherches de symboles au demarrage.

Clouez moi au pilori

Citation:

---

Envoyé par therwald

Y'aurait pas un ./chemin/appli sans ces deux symboles qui traîne par hasard?

---

En effet c'était ça...

J'ai honte -_-'

Plus c'est con, moins on trouve ;)
Mais je me suis déjà fait mordre par ce genre de soucis...et la migraine a tendance à faire des souvenirs tenaces.
bonne continuation :ccool: