Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Variable globale et lib dynamique
Bonjour,
J'ai du code en plusieurs fichiers qui utilise des variables globales, déclarées en extern dans un .h inclut par tous. Cet ensemble est compilé en une lib. Cette lib est ensuite chargée par un autre programme, qui va potentiellement en charger plusieurs (différentes).
Ma question, est-ce que si des variables globales ont le même nom dans plusieurs libs il y aura conflit ou ambiguïté à l'exécution ?
Bonjour,
Il y aura un conflit (une erreur lors de l'édition des liens il me semble) si tes bibliothèques définissent plusieurs fois une variable de même nom. Mais si elles se contentent de déclarer une même variable, le compilateur considérera qu'il s'agit d'une seule et unique variable.Envoyé par ymoreau
Mais il est très facile d'éviter cela en plaçant tes variables dans un namespace ou dans une de tes classes (en statique par exemple).
Les variables globales ne sont pas déclarées plusieurs fois donc pas de problème à l'édition de lien (pour une lib). Ma question est au niveau de l'exécution, quand le programme va charger en mémoire plusieurs libs dynamiques qui auront potentiellement des variables globales de même nom.
Et ce code ne dépend pas de moi, sinon j'aurais évité totalement les variables globales.
Je ne suis pas sûr de bien comprendre.
Bien que tu utilises les bibliothèques de façon dynamique, tu as besoin de leurs .h pour compiler le code qui les utilise. Les variables globales dont tu parles sont forcément définies dans les .h des bibliothèques (sinon elles ne sont pas utilisables à l'extérieur). C'est donc à la compilation que tu vas avoir un problème (lors du parsing des headers), même pas à l'édition de liens.
Je ne suis pas certain de comment elles sont chargées par le programme, mais il n'est pas recompilé, c'est les libs qui sont compilées à la volée et utilisées. Il y a probablement un .h standard pour les libs qui ne tient pas compte de leur "code interne", et les variables globales dont je parle sont justement du "code interne", elles ne sont pas faites pour être utilisées en dehors de la lib, mais à l'intérieur, par les différents sources de la lib.
Pour bien faire une lib chargée dynamiquement devrait englober son code dans un namespace ou autre, mais ce n'est pas le cas (et je n'ai pas vraiment la main dessus). Je voudrais donc savoir si ces variables propres à chaque lib peuvent créer des conflits (ou autre problème, comme une utilisation commune alors qu'il ne faudrait pas).
Ok, donc à priori, il se contente de charger les fonctions dont il a besoin, en utilisant leurs noms (peut-être en passant par un .def). Donc à priori, il n'a pas besoin des headers, ni d'aucun code de ces dlls, donc tu ne devrais pas avoir de problème de redéfinition de variable.
Je dis bien à priori, car ce ne sont que des déductions.
A priori oui il n'utilise qu'une certaine interface de fonctions générique sur la lib. Donc s'il n'utilise que certaines fonctions, les noms des variables/fonctions dans le code de la lib pas utilisés par le programme qui la charge dynamiquement ne sont pas pris en compte du tout par ce programme ?
Merci de vos réponses.
Si la lib est utilisée de façon "full dynamique" (uniquement la dll, et éventuellement un .def), alors oui: le programme qui l'utilise ne charge (et donc ne connait) que ce dont il a besoin.
Je viens juste de m'en souvenir, si un même symbole est présent dans plusieurs .so, c'est le premier rencontré qui est utilisé.
Valgrind, par exemple, se sert de cela pour "redéfinir" les fonctions d'allocations et ainsi repérer les fuites de mémoire.
Sous Linux, il y a d'ailleurs une variable d'environnement qui permet de spécifier les premières bibliothèques à charger justement dans le but de "redéfinir" des symbole sans recompiler.
Sous Windows, une variable globale dans une DLL est spécifique à cette DLL, à moins qu'elle soit exportée (auquel cas, si deux DLLs exportent la même variable, il y aura un conflit entre leurs libs statiques d'importation).
Je n'ai pas précisé mais dans l'occurrence ce serait sous environnement Linux.
Pour détailler un peu le contexte (j'ai eu plus d'informations entre temps), les lib sont effectivement compilées et chargée dynamiquement après le lancement du programme principal. Le programme principal va rechercher des méthodes par leur nom dans la lib (c'est donc par convention et en dur dans le code plutôt que liée par un .h de lib).
Comme je le disais, mon inquiétude serait au niveau des variables déclarées globales au niveau du code de la lib. Est-ce qu'au chargement dynamique le système va "cloisonner" le code de chaque lib ou est-ce qu'il peut y avoir conflit/recouvrement etc avec ces symboles.
Comme toujours en informatique, prépare-toi au pire et tout devrait aller.
En l'occurence, choisis des noms qui t'appartiennent explicitement, parce qu'il y aura probablement du recouvrement.
^ Ça n'évitera pas le problème si l'a.out et le .so utilisent tous deux la même lib statique contenant une variable globale.
^^En fait, je te conseille de tester, c'est encore ce qui marchera le mieux et on peut supposer qu'il n'y aura pas trop de différences d'un Linux à l'autre.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager