Discussion :

[Kaamui]

Bonjour tout le monde,

J'ai toujours "accepté" cette idée sans jamais vraiment me demander pourquoi c'était comme ça, mais ... voilà !

En y réfléchissant, et parce que je ne connais pas plus que ça cette couche bas-niveau où la résolution des noms des fonctions entre en jeu (j'imagine), je n'arrive pas à comprendre pourquoi deux versions d'une même bibliothèque ne pourraient pas coexister.

S'agit-il d'une impossibilité technique, ou d'un choix pratique pour simplifier justement cette étape de résolution des "symboles" ?

Pour prendre un exemple, admettons que je travaille avec une version de Qt construite avec OpenSSL 1.0, et que je veuille utiliser une bibliothèque tierce dans mon programme, elle dépendante d'OpenSSL 1.1. Pourquoi cela peut-il poser problème ?

Attention, je veux une réponse profonde, presque "koalesque" si je peux me permettre. Je ne découvre pas non plus tous ces aspects de nos métiers, mais bon j'aimerais comprendre de manière .... radicale (dans le sens étymologique).

Merci d'avance !

[Bousk]

Pourquoi penses-tu que 2 versions d'une ib ne puissent être utilisées dans un même programme ?
Tu risques d'avoir des collisions de noms mais rien qu'un ajout de namespace ne puisse régler.
Ou encore les libs peuvent embarquer leur propre version de X ou Y lib.
Sur certains projets j'ai vu jusque 4 ziplib en utilisation, toute de version différente parce que chaque lib utilise et intègre sa propre version.

[Kaamui]

je t'avoue que je ne sais plus d'où me vient cette croyance, mais mes récents déboires avec OpenSSL et Qt avaient eu plutôt tendance à me confirmer la chose.

Il ne s'agit peut-être que d'une remarque d'un prof il y a 10 ans qui est resté ou de souci de compatibilité que j'ai pu rencontrer en manipulant plusieurs versions.

J'ai eu des soucis récemment avec Qt pour faire fonctionner une app avec OpenSSL 1.1 alors que Qt lui est compilé avec openssl 1.0.

Qt 5.12.4 a été release cette année avec une note qui dit :

The update to OpenSSL 1.1.1 is important to note for users leveraging OpenSSL in their applications.
We wanted to update now as the earlier version of OpenSSL runs out of support at the end of the year and some platforms, such as Android, need the new one even sooner.
Unfortunately OpenSSL 1.1 is binary incompatible with 1.0, so users need to switch to the new one and repackage their applications.

j'ai eu également le problème en utilisant une bibliothèque liées dynamiquement avec une version Qt différente de celle utilisée par mes soins pour une app (et un message au runtime "conflicting Qt version" ou message proche).

[foetus]

Pour moi, ta question est "bizarre"

C'est le principe du chargement [semi-]dynamique d'une bibliothèque
Pour le chargement statique c'est différent, parce que toute ta bibliothèque se retrouve à l'intérieur de ton exécutable (avec au moins les conflits que cela engendre)

Sous Windows, la fonction LoadLibrary te retourne un HModule et c'est via ce dernier que tu vas faire tes appels.
Donc Qt lui charge son OpenSSL, toi tu charges ton OpenSSL - si ce sont des chargements dynamiques il devrait ne pas y avoir de problème.
Il faut juste faire attention 1) au nom de ta bibliothèque chargée (il doit être unique - par exemple y renseigner la version) 2) au chemin où elle se trouve

Ensuite, là où cela peut coincer, ce sont les objets statiques/ commun.
Par exemple, un fichier temporaire pour un générateur aléatoire. Comme il y a des verrous sur les fichiers, 1 seule bibliothèque peut l'utiliser.

[jo_link_noir]

Pour Qt, le maître mot est "binairement incompatible". C'est tout le problème d'une bibliothèque, l'API évolue et on se retrouve alors dans 3 situations:

- Les types exposés aux utilisateurs changent par l'ajout, suppression ou déplacement de membres: binairement incompatible, le programme ferra n'importe quoi, mais il suffit de recompiler et tout roule. Sauf bien sur si on utilise un membre qui n'existe plus .
- Des fonctions sont supprimées, les signatures changent: binairement incompatible et le programme ne va pas retrouver les fonctions. Pareil que précédemment, il faut recompiler.
- Il y a plein de changement, mais l'API public est stable ou ne contient que l'ajout de fonction: rien à faire.

OpenSSL est dans les 2 premières situations: les APIs public ont changée, les types n'exposent plus les membres, ils sont maintenant opaques et certaines fonctions sont supprimées. Il faut donc recompiler et mettre à jour les applications qui en dépendent et mettre à jour les dépendances des paquets.

Après, au niveau des bibliothèques, il y a un second problème: 2 versions d'une même bibliothèque avec les mêmes noms de fonction ne peuvent pas être linkés: il y a des conflits. On peut pallier à ce problème en chargeant manuellement les bibliothèques. C'est un peu plus fastidieux, mais cela permet de faire cohabiter plusieurs versions d'une même bibliothèque.

[Médinoc]

Et ensuite, il reste les bibliothèques qui emploient des variables globales, qui peuvent être problématiques si elles ne sont pas prévues pour marcher ensemble, ou pas prévues pour garantir l'isolation totale.

[bacelar]

Je viens un "peu" après la guerre mais je pense que c'est juste une confusion entre "bibliothèque" (terme bien trop vague) et Dll chargée statiquement/via le Loader du système.

Sous Windows, les Dll liées "statiquement" ou "delayloaded" sont chargées (plage d'adresses réservée pour y mettre le code binaire de la Dll quand nécessaire, le moment venu) directement par le loader de l'OS, qui se charge (le loader) de patcher le code binaire de l'exécutable ou de tout autre module utilisant cette Dll (les autres Dll statiquement liées à l'exécutable) pour qu'ils fassent des appels indirects aux symboles exportées (variables globales et fonctions libres (les autres, c'est caca )) par la dite Dll via une table d'indirection : les IAT ("Import Address Table").

Ces IAT sont remplies lors du chargement de chaque Dll mais chaque IAT contient les adresses des symboles exportées d'une et une seule Dll. C'est le nom du fichier (oui le nom du fichier, pas le chemin, pas la version, pas le token de sécurité, etc... (mais cela change avec les versions récentes de l'OS et qu'on configure son exécutable cf. ci-après)) qui sert d'identifiant de l'IAT.
Résultat, si un exécutable est lié statiquement à une dll : "Dll1.dll", et qu'il utilise les symboles S1 et S2, le loader va chercher un fichier "Dll1.dll" dans un ensemble de répertoires (avec un ensemble de règle de priorité qui donnerait un mal de crane carabiné même à un poulet décapité), remplira l'IAT avec les adresses virtuelle de S1 et S2 (Si le fichier Dll1.dll trouvé n'exporte pas de S1 et de S2 => erreur au Runtime) et patchera les codes binaires déjà en mémoire.

Maintenant, si votre exécutable utilise aussi une autre Dll, "Dll2.dll", que cela soit via un chargement "statique" ou dynamique, le loader va regarder les dlls nécessaires au bon fonctionnement de la dll "Dll2.dll" via les informations des symboles à importer depuis d'autres dlls (informations dans les en-têtes du fichier image au format PE).
Dans ces informations sur les symboles à importer, il n'y a que le nom du fichier dll et le nom du symbole (voir qu'un numéro de symbole pour certain type d'import "optimisé").

Si "Dll2.dll" a, malheureusement, été construite avec une version de "Dll1.lib" exportant un symbole S3 que "Dll2.dll" utilise, le chargeur cherchera si l'IAT pour "Dll1.dll" existe déjà, ce qui est le cas, il cherchera si le symbole S3 est déjà importé depuis cette dll "Dll1.dll", non, cherchera dans le fichier "Dll1.dll" l'endroit où serait stocké ce symbole S3, (le loader) ne le trouvera pas => erreur au Runtime.

Le problème cardinal, c'est que c'est le nom du fichier dll qui sert de clé pour chercher dans les IAT.

Avec les versions récentes de Windows, on peut configurer le chargeur pour qu'il prennent aussi un token de sécurité et/ou une version de la Dll comme clé de recherche des IAT, en utilisant le mécanisme de manifeste.

[Kaamui]

Merci pour cette réponse en profondeur c'est cool !

Je comprends que sur des bibliothèques multimédia (et sur toute plateforme qui plus est), comme celles que construit Qt, cela devienne une question bien plus sensible vu la complexité des embranchements qu'il doit y avoir avec toutes les dll core sur lesquelles repose chaque version de Qt, d'où l'incompatibilité binaire j'imagine..