Est-il correct d'utiliser DYLD_LIBRARY_PATH sur Mac OS X? Et, quel est l'algorithme de recherche de bibliothèque dynamique avec lui?
J'ai lu quelques articles décourageant l'utilisation de DYLD_LIBRARY_PATH, car le chemin de la bibliothèque dynamique devrait être fixé à l'aide de -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 -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 trouve pas la bibliothèque dynamique? répertoire actuel -> répertoires DYLD_LIBRARY_PATH ...?
Comme vous l'avez noté, DYLD_LIBRARY_PATH se comporte comme LD_LIBRARY_PATH sur un autre * nix. Cependant, il y a une autre variable d'environnement que vous devriez regarder appelée DYLD_FALLBACK_LIBRARY_PATH.
En général, ceux-ci (à la fois sur osx et linux) sont 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 cela est lorsque vous essayez de remplacer l'installation par défaut de VecLib (par exemple blas lapack) avec une installation personnalisée. Cela entraînera des erreurs de symbole introuvable 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) s'il ne l'est pas. 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 dans 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é, retomber 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 avec les bibliothèques par défaut.
En général, lorsque des bibliothèques sont installées à 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 lors de la fourniture d'un chemin absolu, il recherchera d'abord les emplacements spécifiés par DYLD_LIBRARY_PATH:
Lorsque le chemin contient une barre oblique mais n'est pas un chemin de structure (c'est-à-dire un chemin complet ou un chemin partiel vers un dylib), dlopen () recherche les éléments suivants jusqu'à ce qu'il trouve un fichier Mach-O compatible: $ DYLD_LIBRARY_PATH (avec le nom de feuille du 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, les deux appels dlopen suivants:
dlopen("/Hello/libfoo.so", RTLD_NOW);
dlopen("/World/libfoo.so", RTLD_NOW);
résoudra tous les deux en /Hello/libfoo.so. Ceci est assez contre-intuitif et représente une vulnérabilité de sécurité. Un logiciel utilisant dlopen n'a aucun moyen de garantir qu'il charge les bonnes bibliothèques (peut-être remplacer DYLD_LIBRARY_PATH dans son propre environnement?)
Pour obtenir de 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 qui contiennent 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 utilisée par un programme, l'éditeur de liens dynamique le recherche à tour de rôle dans chaque répertoire de DYLD_LIBRARY_PATH. S'il ne trouve toujours pas la bibliothèque, il recherche ensuite DYLD_FALLBACK_FRAMEWORK_PATH et DYLD_FALLBACK_LIBRARY_PATH à tour de rôle.
Utilisez l'option -L pour otool (1). pour découvrir les frameworks et les bibliothèques partagées auxquels l'exécutable est lié.
DYLD_FALLBACK_LIBRARY_PATH
Il s'agit d'une liste de répertoires séparés par deux points qui contiennent 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 défini sur $ (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 qui contiennent des bibliothèques de substitution potentielles. L'éditeur de liens dynamique recherche dans ces répertoires des bibliothèques dynamiques. Pour chaque bibliothèque trouvée, dyld regarde son LC_ID_DYLIB et obtient la version actuelle et le nom d'installation. Dyld recherche ensuite la bibliothèque sur le chemin du nom d'installation. Celui qui a la plus grande valeur courante_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 remplacer, il remplace uniquement si la bibliothèque fournie est plus récente.