Ce chemin n' @loader_path résoudre?

Je vais avoir du mal à comprendre le chemin absolu d'un @loader_path dans un fichier se réfère.

user@local:~$ otool -L zlib.so 
zlib.so:
    @loader_path/../../libz.1.dylib (compatibility version 1.0.0, current version 1.2.7)
    /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)

Je veux savoir où le système à l'air de trouver libz.1.dylib.

De certains Mac documentation:

@loader_path/
Cette variable est remplacée par le chemin vers le répertoire contenant le mach-o binaire qui contient la commande de chargement à l'aide de @loader_path. Ainsi, dans chaque binaire, @loader_path correspond à un chemin d'accès différent

J'aurais deviné cela signifie que @loader_path est juste le chemin vers le fichier de l'objet (zlib.so), mais qui ne semble pas être vrai.

Est-il un utilitaire de ligne de commande qui permet de régler @loader_path au chemin d'accès qui est utilisé lorsque vous essayez d'ouvrir une bibliothèque?

OriginalL'auteur ChrisB | 2013-05-30

  1. 3

    Votre hypothèse est juste: dans ce cas @loader_path est le chemin d'accès au répertoire contenant la librairie zlib.. Mais il y aura probablement des problèmes avec l'utilisation de cette librairie. Où as-tu trouvé cette lib? Si vous êtes à la construction par vous-même, voir cette question pour avoir des infos.


    @Loader_path est utile pour les cadres et les plugins, mais pas pour les bibliothèques autonomes.

    Merci pour la confirmation sur @loader_path. En fin de compte, je veux la liste complète des bibliothèques qu'un fichier objet en dépend, et où le système est en train de regarder pour eux. Est-il un moyen simple de générer la liste?
    Ainsi, le fichier de l'objet ne dépend pas de n'importe quelle bibliothèque. Linker ensembles de dépendances, de sorte que seule binaire cible a des dépendances. Et otool -L <binary> est la façon de les voir. Et toutes les informations supplémentaires qui peuvent aider à résoudre ces chemins est en man dyld (c'est le lien que vous avez fourni)
    Puis-je vous demander pourquoi ce n'est pas utile pour les bibliothèques autonomes? Je suis en train d'essayer d'obtenir une bibliothèque compilée pour être portable. Dois-je utiliser autre chose? Je suis arrivé ici en cherchant ce que @loader_path moyen de blogs.oracle.com/dipol/entry/dynamic_libraries_rpath_and_mac
    Aussi loin que je m'en souviens car @loader_path est sur par rapport de trucs. Dans les plugins que vous avez quelques binaires, qui peuvent être les uns par rapport aux autres, et si vous avez le lien entre eux à l'aide de @loader_path, vous pouvez déplacer le plug-in lui-même à travers le système de fichiers en toute sécurité. Mais dans le cas d'une bibliothèque autonome pourquoi avez-vous besoin de ce chemin? Jetez un oeil à la section à propos de @loader_path dans man dyld pour info
    Merci pour la hausse du niveau de la réponse qui va avec la question, ainsi que l'allusion au fait que l'homme dyld documents!!

    OriginalL'auteur cody