Discussion :

[Médinoc]

1. (for use by the run-time linker, ld.so)

2. ldconfig checks the header and file names of the libraries it
   encounters when determining which versions should have their links
   updated.

   C'est ambigu, ça. Il peut aussi bien s'agir de l'en-tête du fichier, et non pas de fichiers d-en-tête.

3. ldconfig ignores symbolic links when scanning for libraries.

   Sur cette quote par contre, je ne vois pas trop le rapport avec le sujet...

Et aussi: http://unixhelp.ed.ac.uk/CGI/man-cgi?ld.so+8

ld.so loads the shared libraries needed by a program, prepares the pro-
gram to run, and then runs it. Unless explicitly specified via the
-static option to ld during compilation, all Linux programs are incom-
plete and require further linking at run time.

[souviron34]

1. 
   Sur cette quote par contre, je ne vois pas trop le rapport avec le sujet...

Ben si..

Admettons que tu télécharges un soft qui a une .so.

Tu la mets chez toi, dans /home/Medinoc/package1

Soit tu définis (comme mentionné plus haut) le path, soit tu copies la biblio dans /usr/lib, soit il faut que tu crées le lien symbolique dans /usr/lib qui pointe sur ton répertoire.

Si par conséquent tu veux qu'un autre utilisateur y accède, il faut que soit il crée le path, soit il y ait au moins le lien symbolique.

D'où la possibilité pour toi d'écrire dans /usr/lib.

Et là, que ce soit pour la compil (pour que les autres aient accès à la même biblothèque), soit au runtime..

Si maintenant tu as créé ta biblio chez toi, et que tu as créé un lien symbolique dans /usr/lib, quand tu link, même avec ldconfig, il ne suivra pas le lien symbolique... (ce que dit la doc).

Il faudra donc, si tu shippes le binaire, que tu fasses créer par l'utilsateur un /home/medinoc/package1

[Médinoc]

Oui, ça j'avais compris, mais je ne vois pas pourquoi c'était un argument en faveur du "ldconfig, ça change le compile-time et pas le run-time".

Il faut voir la vérité en face, soit tu es passé pendant 17 ans à côté d'une feature clé du loader des unixoïdes, soit ça a été ajouté après que tu l'aies appris...

[souviron34]

Et aussi: http://unixhelp.ed.ac.uk/CGI/man-cgi?ld.so+8

Ce pointeur ne change rien à ce que disait Tchetch, c'est à dire définir le path à la main.... (variable d'environnement).

Mais pas automatiquement....

Oui, ça j'avais compris, mais je ne vois pas pourquoi c'était un argument en faveur du "ldconfig, ça change le compile-time et pas le run-time".

Il faut voir la vérité en face, soit tu es passé pendant 17 ans à côté d'une feature clé du loader des unixoïdes, soit ça a été ajouté après que tu l'aies appris...

je remets ce que j'ai dit juste au dessus :

Si maintenant tu as créé ta biblio chez toi, et que tu as créé un lien symbolique dans /usr/lib, quand tu link, même avec ldconfig, il ne suivra pas le lien symbolique... (ce que dit la doc).

Il faudra donc, si tu shippes le binaire, que tu fasses créer par l'utilsateur un /home/medinoc/package1

Il est tout à fait possible que je sois passé à côté de quelque chose, je ne suis pas omniscient

Mais encore une fois, dans ce cas précis, c'est une question de logique...

[Médinoc]

Si j'ai bien compris, ldconfig permet d'ajouter le répertoire de ton choix aux chemins des bibliothèques dynamiques.

Donc, si je déplace LibMedinoc.so, il suffit d'appeler ldconfig sur le répertoire de destination pour que tous les programmes dépendant de LibMedinoc.so marchent à nouveau...

Edit: Je précise "sans avoir à recompiler".

[souviron34]

sur ta machine, oui. De même avec tes biblios (sans doute encore plus) :

tu as :

• une biblio1.so.
  
• une biblio2.a (ou .so) qui contient des appels à biblio1
  
• un prog qui contient des appels à biblo2.

Tu bouges biblio1.

ldconfig va aller modifer les répertoires dans l'exécutable de prog (arpès recompilation (linker)) et dans biblo2 pour refléter la nouvelle position.

Mais maintenant tu télécharges prog sur une autre machine. Il te faudra biblio1 au même endroit que sur la tienne, sauf si tu modifies le path à la main par la variable d'environnement.

[Médinoc]

Non, je parle bien de la machine de destination:

• Je copie prog là-bas.
• Je copie biblio1.so là-bas.
• J'appelle ldconfig sur l'exécutable où j'ai mis biblio1.so
  
  1. ldconfig met à jour ld.so.cache (et non pas prog)
• Je lance prog
  
  • Le loader charge biblio1.so pour exécuter prog.

(du moins, c'est ce que j'ai personnellement compris de l'article)

Par contre, j'admets qu'il faut sans doute être admin sur le poste de destination pour appeler ldconfig. Mais comme de toute façon, seuls les admins sont censés installer un programme...

[souviron34]

EDIT : c'est possible que cela marche comme le dit Tchetch, MAIS (et c'est un gros mais), cela suppose d'une part d'avoir accès en écriture aux bibliothèques/exécutables/répertoires associés, et d'autre part l'intérêt est plus que limité...

Il est bien plus aisé d'avoir un mini-script "startprog.sh" qui va setter le chemin que d'aller modifier en dur...

Bref, en gros, l'argument est statique, plus gros mais autonome, dynamique, plus petit mais pas autonome

[Médinoc]

Là-dessus, on est d'accord.

Je serais aussi du genre à ajouter "dynamique, plus facile à mettre à jour", mais ça n'est même pas toujours vrai, et beaucoup de gens oublient que si on fait un "breaking change", il est temps de donner un nouveau nom à la lib...