Discussion :

[Monsieur Fromage]

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]

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]

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]

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.

[Monsieur Fromage]

Qu'est ce que tu entends par "le bidule qui fait que le linker trouve les dépendances" ? Parles-tu du rpath ?

[ternel]

probablement, mais en lisant la documentation tu auras la bonne réponse (j'ai un r-link-path ou rpath-link qui traine)

[Monsieur Fromage]

J'ai opté pour la solution rpath et rpath-link ! En effet, j'utilise les deux. Je pense que c'est toujours mieux que de créer directement la dépendance E avec A.so. Merci pour tout ternel !