Ton post est intéressant parce qu'il est inhabituel, mais franchement, je n'ai jamais vu un programmeur douter de l'intérêt des liens dynamiques. Evidement, il y a des cas où le tout statique présente des avantages, mais globalement, quel que soit le nom donné d'ailleurs, les bibliothèques dynamiques s'imposent à peu près partout.
Comme dit plus haut, l'idée générale est de ne pas à avoir à intégrer n fois le même code dans toutes les applications. Non seulement il y a des milliers de binaires en service sur un système, mais ils dépendent tous de routines de plus bas niveau. Si dix applications s'appuient sur dix bibliothèques qui elles-mêmes font appel à dix appels systèmes, tu te retrouves avec 1000 fois le même code. Les bibliothèques dynamiques ne sont pas seulement nécessaires du fait de la multiplication des binaires, mais surtout à cause du caractère exponentiel que présente une édition de liens purement statique, celui-ci étant dù aux dépendances en cascade.
Question 1 : je vois en gros l'interet du link dynamique (vraiment, de loin et en gros), mais les defauts me semble tellement nombreux qu'en fait, non, je vois pas. Les defauts sont notamment qu'on a aucune verif au moment de la compilation/link de la presence/absence des symboles, et que donc faut faire des tests intensif pour etre sur que sur tous les "codepath" de l'apli qu'il n'y'ait pas de relocation error
Non. Avec gcc en tout cas (et donc ld, par conséquent), il faut que tu spécifies à la compilation les bibliothèques impliquées avec l'option "-l", et éventuellement les répertoires dans lesquels elles se trouvent avec "-L". Toutefois, pour rendre la compilation facile, le compilateur peut faire ce travail pour toi envers les bibliothèques standard (stdio et compagnie). Tu peux inhiber ce comportement à l'aide des options « -nostdlib » et « -nodefaultlibs ».
$ man gcc
au chargement du .so, le systeme va voir qu'il connait deja un tata (cui de l'exe) et va donc utiliser ce symbole plutot que cui du so. Donc, notre so, au lieu d'appeler le tata qu'il contient va appeler celui de l'exe.
Non plus, car une fois résolus, les symboles disparaissent (donc en interne) car ils deviennent inutiles, mais surtout ton problème n'a absolument rien à voir avec le caractère dynamique de la gestion des bibliothèques :Si tu compiles un programmes avec une suite de « *.o » purement statiques, tu devras faire face au même problème si deux bibliothèques indépendantes ont décidé d'utiliser le même nom de fonction.
La plupart du temps, le problème ne se pose pas car les noms de symboles ne sont pas limités en longueur (ou en tout cas en tolère un très grand nombre), et les développeurs choisissent en général des noms suffisament explicites pour écarter toute ambigüité. Cependant, dans certains langages tel que le C++, on peut avoir des doubles-emplois. Pour éviter cela, soit les méthodes sont encapsulées dans une classe, dans le cas d'un langage orienté objet, soit les différentes entités sont déclarées au sein d'un namespace ou espace de nommage, que l'on peut décider d'utiliser implicitement au début d'un listing, soit explicitement en utilisant le nom du namespace comme préfixe au symbole que l'on souhaite invoquer.
Mais là encore, c'est totalement indépendant des systèmes de liaison dynamique.
# En voila une drôle de question !
Posté par Obsidian . En réponse au journal Fonctionnement du linker dynamic sous linux. Évalué à 2.
Comme dit plus haut, l'idée générale est de ne pas à avoir à intégrer n fois le même code dans toutes les applications. Non seulement il y a des milliers de binaires en service sur un système, mais ils dépendent tous de routines de plus bas niveau. Si dix applications s'appuient sur dix bibliothèques qui elles-mêmes font appel à dix appels systèmes, tu te retrouves avec 1000 fois le même code. Les bibliothèques dynamiques ne sont pas seulement nécessaires du fait de la multiplication des binaires, mais surtout à cause du caractère exponentiel que présente une édition de liens purement statique, celui-ci étant dù aux dépendances en cascade.
Non. Avec gcc en tout cas (et donc ld, par conséquent), il faut que tu spécifies à la compilation les bibliothèques impliquées avec l'option "-l", et éventuellement les répertoires dans lesquels elles se trouvent avec "-L". Toutefois, pour rendre la compilation facile, le compilateur peut faire ce travail pour toi envers les bibliothèques standard (stdio et compagnie). Tu peux inhiber ce comportement à l'aide des options « -nostdlib » et « -nodefaultlibs ».
$ man gcc
Non plus, car une fois résolus, les symboles disparaissent (donc en interne) car ils deviennent inutiles, mais surtout ton problème n'a absolument rien à voir avec le caractère dynamique de la gestion des bibliothèques :Si tu compiles un programmes avec une suite de « *.o » purement statiques, tu devras faire face au même problème si deux bibliothèques indépendantes ont décidé d'utiliser le même nom de fonction.
La plupart du temps, le problème ne se pose pas car les noms de symboles ne sont pas limités en longueur (ou en tout cas en tolère un très grand nombre), et les développeurs choisissent en général des noms suffisament explicites pour écarter toute ambigüité. Cependant, dans certains langages tel que le C++, on peut avoir des doubles-emplois. Pour éviter cela, soit les méthodes sont encapsulées dans une classe, dans le cas d'un langage orienté objet, soit les différentes entités sont déclarées au sein d'un namespace ou espace de nommage, que l'on peut décider d'utiliser implicitement au début d'un listing, soit explicitement en utilisant le nom du namespace comme préfixe au symbole que l'on souhaite invoquer.
Mais là encore, c'est totalement indépendant des systèmes de liaison dynamique.