Exportations de symboles entre plusieurs biblioth�ques dynamiques (.so) en C++

**Monsieur Fromage** · 23/03/2017, 10h41

Bonjour,

Je souhaite pouvoir exporter des symboles de fonction correctement � travers plusieurs biblioth�ques dynamiques en C++. En effet, pour sch�matiser, j'ai 2 biblioth�ques dynamiques A et B et un ex�cutable E. Aux niveaux des d�pendances, B d�pend de A et E d�pend de B. Donc le makefile de B je link avec A et dans le makefile de E je link uniquement avec B. Mon ex�cutable E appelle une fonction de B qui elle-m�me appelle une fonction de A. Mon probl�me est le suivant : Au link de mon ex�cutable E, j'ai une r�f�rence ind�finie vers la fonction de A. Suis-je obliger de linker directement avec A ? Est-il possible de passer des options de link dans le makefile de A, B ou E pour �viter cela ?

Merci de votre aide,

Cordialement

Ps : J'ai essay� plusieurs solutions, telles que placer __attribute__ ((visibility ("default"))) devant les fonctions que je souhaitais exporter et de rajouter le Flag -fvisibility = hidden / default

**ternel** · 23/03/2017, 12h31

une r�f�rence ind�finie, c'est un probl�me de linker qui ne trouve pas un morceau.
La r�ponse est: il faut ajouter A.so comme d�pendance dans B.so, ce qui est fait avec un des rpath.

Le probl�me, c'est qu'il faut un chemin absolu, et donc qu'il faut le corriger lors de l'installation de B.so, si elle n'est pas construite sur la version install�e de A.

**Monsieur Fromage** · 23/03/2017, 12h49

Mon probl�me n'est pas au runtime comme tu l'as laiss� entendre mais bien au link apr�s la compilation de mon ex�cutable. Le rpath sert au runtime. De plus, comme je l'ai expliqu�, j'ai d�j� ajout� A.so comme d�pendance de B.so. Enfin l'ex�cutable E a pour d�pendance B.so.

A.so <- B.so <- E Pour r�soudre mes probl�mes de r�f�rences ind�finies de E avec une fonction de B.so qui appelle elle-m�me une fonction de A.so, suis-je oblig� de faire d�pendre A.so � E ou y'a t-il d'autres solutions ?

**ternel** · 23/03/2017, 14h39

Le "runtime" et le "linktime" se r�unnissent sur ce point.

En r�alit�, le link n'est pas compl�tement fait au linktime. Les biblioth�ques externes sont effectivement li�es au tout d�but de l'ex�cution.
En gros, les adresses du code des fonctions de la biblioth�ques sont donn�es par rapport � l'adresse de la biblioth�que, qui est d�finie au chargement de l'ex�cutable.

Le linker peut se servir d'un des rpaths d'une biblioth�que pour trouver les biblioth�ques dont elle d�pend.

Les seules fois o� j'ai rencontr� ce probl�me, j'utilisais cmake, et on voit passer des messages du genre "editing rpath".

Tu as donc deux solutions: linker sur A, ou ajouter A dans "le bidule qui fait que le linker trouve les d�pendances" de B.
Dans les deux cas, par le travail du linker, l'ex�cutable devrait avoir A sa table des lib � lier.

Note que certaines biblioth�ques classiques optent pour "lier tout, s'il vous plait". C'est par exemple le cas de la SFML, de la SDL.