Liens dynamique à la compilation
Fermé
abso22
Messages postés
4
Date d'inscription
samedi 17 juin 2017
Statut
Membre
Dernière intervention
20 juin 2017
-
17 juin 2017 à 13:41
[Dal] Messages postés 6174 Date d'inscription mercredi 15 septembre 2004 Statut Contributeur Dernière intervention 2 février 2024 - 20 juin 2017 à 12:33
[Dal] Messages postés 6174 Date d'inscription mercredi 15 septembre 2004 Statut Contributeur Dernière intervention 2 février 2024 - 20 juin 2017 à 12:33
A voir également:
- Liens dynamique à la compilation
- Tableau croisé dynamique - Guide
- Liste déroulante dynamique excel - Guide
- Le point d'entrée de procédure est introuvable dans la bibliothèque de liens dynamiques ✓ - Forum Windows
- Les données fournies dans le fichier à télécharger peuvent être synthétisées par le tableau récapitulatif suivant. dans le fichier, générez ce tableau automatiquement (tableau croisé dynamique ou table de pilote) à partir des 4 premières colonnes. cinq valeurs manquent dans le tableau suivant. retrouvez-les dans votre tableau puis reportez-les, arrondies à l’entier le plus proche, dans la zone de réponse. ✓ - Forum Jeux vidéo
- Point d'entrée introuvable dans KERNEL32.dll ✓ - Forum Windows
3 réponses
YCN-
Messages postés
116
Date d'inscription
mercredi 24 juin 2015
Statut
Membre
Dernière intervention
13 juillet 2017
12
19 juin 2017 à 11:55
19 juin 2017 à 11:55
Il me semble que oui, le but des librairies dynamiques est bien d'aller chercher cette librairie en particulier là ou tu exécutes le programme. Ca a ses avantages et ses inconvénients comme tu peux t'en douter.
Maintenant je ne saurais pas te dire exactement comment le compilateur fait ni exactement comment ces librairies fonctionnent.
De ce que j'en ai compris en fait à l’exécution le programme va aller chercher le binaire de la fonction dans la librairie. C'est pour ça que les programme utilisant des librairies dynamiques sont beaucoup plus légers que ceux qui utilisent des libairies statiques. Cependant si par malheur cette librairie venait à disparaître ou à changer ou à être mis à jour, il y a le risque de rendre le pgm obsolète.
Maintenant je ne saurais pas te dire exactement comment le compilateur fait ni exactement comment ces librairies fonctionnent.
De ce que j'en ai compris en fait à l’exécution le programme va aller chercher le binaire de la fonction dans la librairie. C'est pour ça que les programme utilisant des librairies dynamiques sont beaucoup plus légers que ceux qui utilisent des libairies statiques. Cependant si par malheur cette librairie venait à disparaître ou à changer ou à être mis à jour, il y a le risque de rendre le pgm obsolète.
Sugel
Messages postés
4070
Date d'inscription
jeudi 18 août 2011
Statut
Membre
Dernière intervention
19 juin 2017
724
19 juin 2017 à 12:24
19 juin 2017 à 12:24
Ton programme dynamique va avoir des endroits réservés pour être plus tard remplis avec l'adresse mémoire des fonctions provenant de bibliothèques dynamiques.
Le programme chargé de remplir ces trous avec l'adresse des fonctions demandées est appellé linker dynamique.
https://linux.die.net/man/8/ld.so
Le programme chargé de remplir ces trous avec l'adresse des fonctions demandées est appellé linker dynamique.
https://linux.die.net/man/8/ld.so
abso22
Messages postés
4
Date d'inscription
samedi 17 juin 2017
Statut
Membre
Dernière intervention
20 juin 2017
20 juin 2017 à 00:33
20 juin 2017 à 00:33
Merci Sugel,
J'ai fait une recherche sur linker dynamique et j'ai lu ton lien, je comprends bien le fonctionnement maintenant.
merci à toi pour ta réponse
J'ai fait une recherche sur linker dynamique et j'ai lu ton lien, je comprends bien le fonctionnement maintenant.
merci à toi pour ta réponse
[Dal]
Messages postés
6174
Date d'inscription
mercredi 15 septembre 2004
Statut
Contributeur
Dernière intervention
2 février 2024
1 083
Modifié le 19 juin 2017 à 13:48
Modifié le 19 juin 2017 à 13:48
Salut abso22,
Si je fais un .exe avec des éditions de liens dynamiques en utilisant des bibliothèques mises à disposition sur un système et que ensuite je j'installe le programme sur un autre PC.
Comment se fait la liaison sur les liens ?
L'exécutable va chercher sur des emplacements particuliers les bibliothèques dynamiques qu'il est sensé utiliser, et dont les noms (mais pas le contenu) ont été insérés dans l'exécutable lors de la phase d'édition de liens. La localisation de ces emplacements dépend du système d'exploitation, ainsi que la façon dont les bibliothèques sont chargées.
Puisque tu parles d'exe, sous Windows ces bibliothèques ont pour extension .dll, et elles seront recherchées comme cela (et dans cet ordre) : https://docs.microsoft.com/en-us/previous-versions/7d83bc18(v=vs.140)?redirectedfrom=MSDN
1. The directory where the executable module for the current process is located.
2. The current directory.
3. The Windows system directory. The GetSystemDirectory function retrieves the path of this directory.
4. The Windows directory. The GetWindowsDirectory function retrieves the path of this directory.
5. The directories listed in the PATH environment variable.
C'est pendant l'installation, le système va par certains mécanismes indiquer au code source ou sont les librairie lui permettant de résoudre ses appels ?
Non. De plus, tu parles du "code source", ce qui n'a plus de sens puisque ta prémisse est que tu distribues l'exécutable.
Si une .dll nécessaire à l'exécution de ton programme ne se trouve pas sur l'autre PC, un message d'erreur s'affichera à l'exécution s'en plaignant.
Dal
Si je fais un .exe avec des éditions de liens dynamiques en utilisant des bibliothèques mises à disposition sur un système et que ensuite je j'installe le programme sur un autre PC.
Comment se fait la liaison sur les liens ?
L'exécutable va chercher sur des emplacements particuliers les bibliothèques dynamiques qu'il est sensé utiliser, et dont les noms (mais pas le contenu) ont été insérés dans l'exécutable lors de la phase d'édition de liens. La localisation de ces emplacements dépend du système d'exploitation, ainsi que la façon dont les bibliothèques sont chargées.
Puisque tu parles d'exe, sous Windows ces bibliothèques ont pour extension .dll, et elles seront recherchées comme cela (et dans cet ordre) : https://docs.microsoft.com/en-us/previous-versions/7d83bc18(v=vs.140)?redirectedfrom=MSDN
1. The directory where the executable module for the current process is located.
2. The current directory.
3. The Windows system directory. The GetSystemDirectory function retrieves the path of this directory.
4. The Windows directory. The GetWindowsDirectory function retrieves the path of this directory.
5. The directories listed in the PATH environment variable.
C'est pendant l'installation, le système va par certains mécanismes indiquer au code source ou sont les librairie lui permettant de résoudre ses appels ?
Non. De plus, tu parles du "code source", ce qui n'a plus de sens puisque ta prémisse est que tu distribues l'exécutable.
Si une .dll nécessaire à l'exécution de ton programme ne se trouve pas sur l'autre PC, un message d'erreur s'affichera à l'exécution s'en plaignant.
Dal
abso22
Messages postés
4
Date d'inscription
samedi 17 juin 2017
Statut
Membre
Dernière intervention
20 juin 2017
20 juin 2017 à 00:30
20 juin 2017 à 00:30
Bonjour Dal,
merci pour ta réponse c'est exactement ce que je ne comprenais pas. C'est plus claire pour moi.
Mais je ne dois pas toujours fournir toutes les dll que j'utilise dans mes bibliothèques dynamiques ?
Comme tu me le dit, une fois j'ai installé un soft et ça a planté en me me disant justement qu'une dll était manquante.
J'imagine donc que certaines dll essentielles au système y sont par défaut sur les OS concernés et lors de l'installation, ces DLL sont retrouvées par le système si existantes car :
La localisation de ces emplacements dépend du système d'exploitation, ainsi que la façon dont les bibliothèques sont chargées.
Si j'ai bien compris...
merci à vous pour votre aide.
merci pour ta réponse c'est exactement ce que je ne comprenais pas. C'est plus claire pour moi.
Mais je ne dois pas toujours fournir toutes les dll que j'utilise dans mes bibliothèques dynamiques ?
Comme tu me le dit, une fois j'ai installé un soft et ça a planté en me me disant justement qu'une dll était manquante.
J'imagine donc que certaines dll essentielles au système y sont par défaut sur les OS concernés et lors de l'installation, ces DLL sont retrouvées par le système si existantes car :
La localisation de ces emplacements dépend du système d'exploitation, ainsi que la façon dont les bibliothèques sont chargées.
Si j'ai bien compris...
merci à vous pour votre aide.
YCN-
Messages postés
116
Date d'inscription
mercredi 24 juin 2015
Statut
Membre
Dernière intervention
13 juillet 2017
12
20 juin 2017 à 09:34
20 juin 2017 à 09:34
Salut,
Sur Linux elles sont dans /usr/lib , on retrouve là bas toutes les librairies utilisés.
Sur windows elles se trouvent dans C:\Windows\System32
Donc par défaut on va regarder dans le dossier ou l'éxécutable est, et si il n'y a rien on va regarder dans le dossier des DLL ou des .so pour Linux.
Voilà voilà :)
Sur Linux elles sont dans /usr/lib , on retrouve là bas toutes les librairies utilisés.
Sur windows elles se trouvent dans C:\Windows\System32
Donc par défaut on va regarder dans le dossier ou l'éxécutable est, et si il n'y a rien on va regarder dans le dossier des DLL ou des .so pour Linux.
Voilà voilà :)
[Dal]
Messages postés
6174
Date d'inscription
mercredi 15 septembre 2004
Statut
Contributeur
Dernière intervention
2 février 2024
1 083
Modifié le 20 juin 2017 à 13:00
Modifié le 20 juin 2017 à 13:00
Salut abso22,
1.
J'imagine donc que certaines dll essentielles au système y sont par défaut sur les OS concernés et lors de l'installation, ces DLL sont retrouvées par le système si existantes (...)
oui, personne n'a dit que c'était simple ... :-)
Certaines .dll vont se retrouver sur un système Windows actuel normalement constitué, telles que kernel32.dll or ntdll.dll, d'autres n'existeront sur un système Windows que dans certaines versions, d'autres ne font pas partie d'un système Windows habituel, et seront installées ou pas, dépendront de l'environnement de développement utilisé (MFC, .NET, Cygwin, MinGW,...), de bibliothèques externes utilisées pour gérer l'interface utilisateur (GTK+, KDE,...), ou pour ajouter tout types de fonctionnalités non offertes par le langage en standard.
La personne distribuant son programme devra soit (i) l'accompagner des .dll nécessaires (si elle en a le droit) avec un programme d'installation s'occupant d'installer les choses nécessaires; soit (ii) fournir des instructions permettant à l'utilisateur de savoir où et comment se procurer les "dépendances".
Il existe des outils pour créer le programme d'installation.
Microsoft a le sien, mais tu peux aussi utiliser des logiciels libres comme Inno Setup (que je trouve bien fait et assez facile d'utilisation), ou NSIS, il y a aussi WiX de la .NET Foundation.
Il existe aussi des outils permettant de vérifier exhaustivement toutes .dll constituant des dépendances d'un programme. Ainsi, cet outil gratuit de Microsoft : Dependency Walker (depend.exe) permet de le faire.
2.
Sous Linux, les bibliothèques dynamiques sont stockées dans des emplacements standards, et portent l'extension .so (shared object).
On les trouve dans
La façon et l'ordre dans lequel un système Linux va chercher les .so sont spécifiés dans la page de manuel de
Sous Linux, il est rare que les binaires (les exécutables) soient statiquement liés, et en général les binaires ne sont pas distribués en package d'installation incluant leurs dépendances.
Les systèmes Linux utilisent en général des systèmes de gestion de paquets permettant de résoudre les dépendances et d'installer automatiquement les éléments manquants sur le système à partir de dépôts officiels maintenus par la distribution Linux concernée, où se trouvent des paquets prêts à l'installation, couvrant non seulement des éléments directement liés au système Linux, mais aussi des bibliothèques tierces intégrées au dépôt.
Tu peux voir, par exemple, les packages mis à disposition par Debian Linux : https://www.debian.org/distrib/packages
Du coup, cela simplifie la vie du développeur (et de l'utilisateur, en principe), qui n'a qu'à indiquer les paquets nécessaires et leurs versions minimales) lorsqu'il conçoit son package.
Les packages ne sont pas eux-mêmes des exécutables (quoiqu'ils peuvent contenir des scripts lancés après copie des fichiers, par exemple). Ils portent des extensions différentes selon les systèmes de gestion de paquets, par exemple .deb (pour systèmes basés sur Debian : MEPIS, Ubuntu, Kubuntu, Linux Mint,...), ou .rpm (RedHat, Fedora, CentOS, Mageia,...), et sont traités par les systèmes de gestion de paquets correspondants.
Le packaging se fait avec des outils fournis par le système. Par exemple, sous Debian, vois https://wiki.debian.org/HowToPackageForDebian tout y est très bien expliqué et détaillé.
Dal
1.
J'imagine donc que certaines dll essentielles au système y sont par défaut sur les OS concernés et lors de l'installation, ces DLL sont retrouvées par le système si existantes (...)
oui, personne n'a dit que c'était simple ... :-)
Certaines .dll vont se retrouver sur un système Windows actuel normalement constitué, telles que kernel32.dll or ntdll.dll, d'autres n'existeront sur un système Windows que dans certaines versions, d'autres ne font pas partie d'un système Windows habituel, et seront installées ou pas, dépendront de l'environnement de développement utilisé (MFC, .NET, Cygwin, MinGW,...), de bibliothèques externes utilisées pour gérer l'interface utilisateur (GTK+, KDE,...), ou pour ajouter tout types de fonctionnalités non offertes par le langage en standard.
La personne distribuant son programme devra soit (i) l'accompagner des .dll nécessaires (si elle en a le droit) avec un programme d'installation s'occupant d'installer les choses nécessaires; soit (ii) fournir des instructions permettant à l'utilisateur de savoir où et comment se procurer les "dépendances".
Il existe des outils pour créer le programme d'installation.
Microsoft a le sien, mais tu peux aussi utiliser des logiciels libres comme Inno Setup (que je trouve bien fait et assez facile d'utilisation), ou NSIS, il y a aussi WiX de la .NET Foundation.
Il existe aussi des outils permettant de vérifier exhaustivement toutes .dll constituant des dépendances d'un programme. Ainsi, cet outil gratuit de Microsoft : Dependency Walker (depend.exe) permet de le faire.
2.
Sous Linux, les bibliothèques dynamiques sont stockées dans des emplacements standards, et portent l'extension .so (shared object).
On les trouve dans
/usr/libcomme dit par YCN- (ou
/lib, ces emplacements étant parfois suffixés avec 64), mais les standards GNU recommandent comme une meilleure pratique que cet emplacement soit réservé au système, et que les bibliothèques tierces soient installées dans
/usr/local/lib.
La façon et l'ordre dans lequel un système Linux va chercher les .so sont spécifiés dans la page de manuel de
ld.so, comme indiqué par Sugel.
Sous Linux, il est rare que les binaires (les exécutables) soient statiquement liés, et en général les binaires ne sont pas distribués en package d'installation incluant leurs dépendances.
Les systèmes Linux utilisent en général des systèmes de gestion de paquets permettant de résoudre les dépendances et d'installer automatiquement les éléments manquants sur le système à partir de dépôts officiels maintenus par la distribution Linux concernée, où se trouvent des paquets prêts à l'installation, couvrant non seulement des éléments directement liés au système Linux, mais aussi des bibliothèques tierces intégrées au dépôt.
Tu peux voir, par exemple, les packages mis à disposition par Debian Linux : https://www.debian.org/distrib/packages
Du coup, cela simplifie la vie du développeur (et de l'utilisateur, en principe), qui n'a qu'à indiquer les paquets nécessaires et leurs versions minimales) lorsqu'il conçoit son package.
Les packages ne sont pas eux-mêmes des exécutables (quoiqu'ils peuvent contenir des scripts lancés après copie des fichiers, par exemple). Ils portent des extensions différentes selon les systèmes de gestion de paquets, par exemple .deb (pour systèmes basés sur Debian : MEPIS, Ubuntu, Kubuntu, Linux Mint,...), ou .rpm (RedHat, Fedora, CentOS, Mageia,...), et sont traités par les systèmes de gestion de paquets correspondants.
Le packaging se fait avec des outils fournis par le système. Par exemple, sous Debian, vois https://wiki.debian.org/HowToPackageForDebian tout y est très bien expliqué et détaillé.
Dal
19 juin 2017 à 12:31
"De ce que j'en ai compris en fait à l’exécution le programme va aller chercher le binaire de la fonction dans la librairie"
pas vraiment, c'est un composant appellé linker dynamique qui s'en charge. celui-ci peut être ou non inclu dans l'OS.
"Cependant si par malheur cette librairie venait à disparaître ou à changer ou à être mis à jour, il y a le risque de rendre le pgm obsolète."
la plupart des librairies sont rétrocompatibles: les nouvelles versions gardent le même comportement que les précédentes, ce qui limite l'étendue du problème.
"Ca a ses avantages et ses inconvénients comme tu peux t'en douter."
les avantages sont: moins d'usage mémoire, car deux programmes partagent du code (renseigne toi sur la mémoire virtuelle et le paging pour plus de détails), pas de duplication de code, mises à jour facilitées (pas besoin de recompiler ton programme quand une nouvelle lib sort)
Sur des systèmes bien gérés, les inconvénients sont vraiment minimes. Il arrive parfois qu'un système mal conçu aie des problèmes de versions de bibliothèques. Ce problème est particulièrement présent sous windows, où aucune solution n'est fournie.
20 juin 2017 à 00:35
merci pour ta réponse.