Est-il correct d'utiliser le chemin de la bibliothèque dyld sur Mac OS X? Et, quel est l'algorithme de recherche de bibliothèque dynamique avec elle?
J'ai lu quelques articles décourageant l'utilisation de DYLD_LIBRARY_PATH, car le chemin de la Bibliothèque dynamique devrait être corrigé en utilisant-install_name, @rpath et @loader_path.
En termes de création d'un programme qui s'exécute à la fois sur Linux et Mac OS X, Dyld_library_path de Mac OS X fait exactement ce que LD_LIBRARY_PATH de Linux. Et, nous pouvons partager (presque) le même fichier make qui n'a pas le-install_name et @rpath.
- Est-ce correct d'utiliser DYLD_LIBRARY_PATH sur Mac OS X?
- Quel est l'algorithme de recherche de bibliothèque dynamique avec Mac OS X lorsque le binaire ne peut pas trouver la Bibliothèque dynamique? répertoire courant - > répertoires DYLD_LIBRARY_PATH ... ?
3 réponses
Comme vous l'avez remarqué, DYLD_LIBRARY_PATH se comporte comme LD_LIBRARY_PATH sur les autres *nix. Cependant, il existe une autre variable d'environnement que vous devriez regarder appelée DYLD_FALLBACK_LIBRARY_PATH.
En général, ceux-ci sont (à la fois sur osx et linux) suggérés uniquement pour le développement car ils peuvent provoquer des erreurs de recherche de symboles lorsque vous remplacez avec une bibliothèque qui n'a pas la même table de symboles. Un bon exemple de ceci est lorsque vous essayez de remplacer L'installation par défaut de VecLib (par exemple blas lapack) avec une installation personnalisée. Ce sera la cause de symbole introuvable erreurs dans les applications liées au système VecLib si DYLD_LIBRARY_PATH est défini et l'inverse (erreurs de recherche de symboles dans les applications personnalisées) si ce n'est pas le cas. Cela est dû au fait que le système blas / lapack n'est pas une implémentation complète des bibliothèques ATLAS.
DYLD_FALLBACK_LIBRARY_PATH ne produira pas ces problèmes.
Lors de l'installation de bibliothèques à un emplacement non standard, DYLD_FALLBACK_LIBRARY_PATH est beaucoup plus sain d'esprit. Cela recherchera les symboles dans les bibliothèques fournies dans les chemins par défaut et si le symbole n'y est pas trouvé, tomber en arrière sur le chemin spécifié.
L'avantage est que ce processus ne provoquera pas d'erreurs de recherche de symboles dans les applications compilées par rapport aux bibliothèques par défaut.
En général, lorsque les bibliothèques sont installées dans des emplacements non standard, des chemins absolus doivent être spécifiés, ce qui annule l'ambiguïté de la recherche dynamique.
DYLD_LIBRARY_PATH ne se comporte pas comme LD_LIBRARY_PATH. La documentation OS X dlopen(https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man3/dlopen.3.html) spécifie que lorsque vous fournissez un chemin absolu, il regarde d'abord dans les emplacements spécifiés par DYLD_LIBRARY_PATH:
Lorsque path contient une barre oblique mais n'est pas un chemin d'Infrastructure (c'est-à-dire un chemin complet ou un chemin partiel vers un dylib), dlopen() recherche ce qui suit jusqu'à ce qu'il trouve un fichier Mach-O compatible: $DYLD_LIBRARY_PATH (avec feuille chemin), puis le chemin fourni (en utilisant le répertoire de travail actuel pour les chemins relatifs), puis $DYLD_FALLBACK_LIBRARY_PATH (avec le nom de feuille du chemin).
En d'autres termes, si vous définissez DYLD_LIBRARY_PATH à /Hello, la suite de deux dlopen appels:
dlopen("/Hello/libfoo.so", RTLD_NOW);
dlopen("/World/libfoo.so", RTLD_NOW);
Résoudra tous les deux à /Hello/libfoo.so. Ceci est tout à fait contre-intuitif, et représente une vulnérabilité de sécurité. Le logiciel utilisant dlopen n'a aucun moyen de garantir qu'il charge les bibliothèques correctes (peut-être remplacer DYLD_LIBRARY_PATH dans son propre environnement?)
Pour la documentation sur les variables d'environnement de l'éditeur de liens dynamiques et leur incidence sur la recherche de bibliothèques dynamiques, man dyld.
DYLD_LIBRARY_PATH
Il s'agit d'une liste de répertoires séparés par deux points contenant des bibliothèques. L'éditeur de liens dynamique recherche ces répertoires avant de rechercher les emplacements par défaut des bibliothèques. Il vous permet de tester de nouvelles versions de bibliothèques existantes.
Pour chaque bibliothèque qu'un programme utilise, l'éditeur de liens dynamique recherche dans chaque répertoire dans dyld_library_path à son tour. S'il ne trouve toujours pas la bibliothèque, il recherche ensuite dyld_fallback_framework_path et dyld_fallback_library_path à son tour.
Utilisez l'option-L pour otool(1). pour découvrir les frameworks et bibliothèques partagées que l'exécutable est lié contre.
DYLD_FALLBACK_LIBRARY_PATH
Il s'agit d'une liste de répertoires séparés par deux points contenant des bibliothèques. Il est utilisé comme emplacement par défaut pour les bibliothèques introuvables dans leur chemin d'installation. Par défaut, il est fixé à $(HOME)/lib:/usr/local/lib:/lib:/usr/lib.
DYLD_VERSIONED_LIBRARY_PATH
Il s'agit d'une liste de répertoires séparés par deux points contenant des bibliothèques de remplacement potentielles. L'éditeur de liens dynamiques recherche dans ces répertoires des bibliothèques dynamiques. Pour chaque bibliothèque trouvée, dyld regarde son LC_ID_DYLIB et obtient le nom current_version et install. Dyld cherche alors la bibliothèque au installez le chemin du nom. Celui qui a la plus grande valeur current_version sera utilisé dans le processus chaque fois qu'un dylib avec ce nom d'installation est requis. Ceci est similaire à DYLD_LIBRARY_PATH sauf qu'au lieu de toujours surcharger, il ne remplace que la bibliothèque fournie est plus récente.