Signaler

Liens dynamique à la compilation

Posez votre question abso22 4Messages postés samedi 17 juin 2017Date d'inscription 20 juin 2017 Dernière intervention - Dernière réponse le 20 juin 2017 à 12:33 par [Dal]
Bonjour,

Je suis étudiant en informatique et nous avons vu la compilation de programme en C avec les éditions de liens dynamiques et statiques, cependant j'ai une question qui je crois n'a pas été abordée dans mon cours.
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 ? 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 ?

merci pour vos retours.
Afficher la suite 
Utile
+0
plus moins
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.
Sugel 4293Messages postés jeudi 18 août 2011Date d'inscription 19 juin 2017 Dernière intervention - 19 juin 2017 à 12:31
c'est ça oui.

"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.
Répondre
abso22 4Messages postés samedi 17 juin 2017Date d'inscription 20 juin 2017 Dernière intervention - 20 juin 2017 à 00:35
Bonjour Ycn,

merci pour ta réponse.
Répondre
Donnez votre avis
Utile
+0
plus moins
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
abso22 4Messages postés samedi 17 juin 2017Date d'inscription 20 juin 2017 Dernière intervention - 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
Répondre
Donnez votre avis
Utile
+0
plus moins
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://msdn.microsoft.com/en-us/library/7d83bc18.aspx

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 4Messages postés samedi 17 juin 2017Date d'inscription 20 juin 2017 Dernière intervention - 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.
Répondre
YCN- 138Messages postés mercredi 24 juin 2015Date d'inscription 26 juin 2017 Dernière intervention - 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à :)
Répondre
[Dal] 4342Messages postés mercredi 15 septembre 2004Date d'inscription ContributeurStatut 26 juin 2017 Dernière intervention - 20 juin 2017 à 12:33
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
/usr/lib
comme 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://packages.debian.org/

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
Répondre
Donnez votre avis

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes.

Le fait d'être membre vous permet d'avoir des options supplémentaires.

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !