El Capitan, faites chèque, DYLD_LIBRARY_PATH

Je développe des applications en utilisant l'ensemble d'outils Unix habituel: un compilateur make, et des bibliothèques partagées. La procédure est alors traditionnellement quelque chose comme

• ./configure, qui adapte les sources aux caractéristiques de la machine sur laquelle il est exécuté,
• make, qui compile en fait les bibliothèques partagées, les exécutables, etc.,
• make check, qui exécute les tests avant d' installer le package,
• make install, si le package se comporte correctement, et enfin, éventuellement,
• make installcheck, pour vous assurer que l'installation fonctionne.

Pendant make, les bibliothèques partagées et les exécutables sont compilés dans leur forme finale: les exécutables sont compilés avec une dépendance aux bibliothèques partagées dans leur destination finale (c'est-à-dire qu'ils dépendent des bibliothèques /usr/local/libbien qu'ils ne soient pas encore là, ils sont toujours dans la build arbre). Il make installs'agit alors, en gros, d'utiliser simplement cppour installer les bibliothèques et les exécutables de l'arborescence de construction à l'emplacement final.

Pendant la make checkphase, nous exécutons le programme désinstallé: les bibliothèques partagées, les exécutables et les fichiers auxiliaires sont toujours dans l'arborescence de construction. Pour exécuter les tests, vous devez configurer quelques variables d'environnement personnalisées (par exemple pour indiquer à votre programme que vos fichiers de données auxiliaires ne sont pas dans /usr/local/sharemais dans l'arborescence source), et certaines variables d'environnement système, pour indiquer à votre chargeur de bibliothèque de partage de regarder pour les bibliothèques partagées. Les variables d'environnement sur les Unices traditionnels sont LD_LIBRARY_PATH, sur OS X, elles le sont DYLD_LIBRARY_PATH. Cela a fonctionné pendant (des dizaines) d'années.

Mais maintenant, El Capitan a cassé cela.

$ (export FOO=foo; env) | grep foo
FOO=foo
$ (export DYLDFOO=foo; env) | grep foo
DYLDFOO=foo
$ (export DYLD_FOO=foo; env) | grep foo
$

maintenant, lorsque SIP est activé, no DYLD_*est exporté d'un processus vers ses enfants.

Ma question est donc la suivante: comment exécuter des programmes qui ne sont pas installés? Quelle est la procédure à suivre pour pouvoir exécuter la séquence Unix traditionnelle ./configure && make && make check?

S'il vous plaît , aucune réponse telle que "exécuter en make installpremier". Ce n'est pas le propos. Je suis développeur et j'exécute très fréquemment "make check" (et plus généralement une version non installée d'un programme). Même l'installation dans un endroit factice prend du temps. J'ai besoin de quelque chose d'efficacité et d' efficience. Et la désactivation de SIP ne résoudra pas le problème pour les utilisateurs de mes packages qui souhaitent s'exécuter make check.

Il semble que DYLD_ * ne soit supprimé que pour les binaires «protégés» (je ne sais pas exactement ce que cela signifie, mais apparemment quoi que ce soit dans / bin et / usr / bin pour commencer) Cependant, si vous copiez / usr / bin / env ailleurs, il conserve ses fichiers DYLD_ *:

$ cp /usr/bin/env ~/Desktop; (DYLD_FOO=bar ~/Desktop/env)|grep DY
dyld: warning, unknown environment variable: DYLD_FOO
DYLD_FOO=bar

Je pense que make exécute toujours les commandes via / bin / sh, donc vous ne pouvez pas définir de variables «dangereuses» dans le makefile et les faire affecter les commandes, mais peut-être pourriez-vous déplacer le test dans un script shell, définir les variables d'environnement à l'intérieur du puis appelez le script depuis make. Bien évidemment, cela ne vous aidera pas si les tests, à leur tour, s'appuient sur des scripts shell (ou si les choses testées sont des scripts shell!) Car alors ils vont invoquer / bin / sh et perdre à nouveau les variables .. .