Impossible de définir DYLD_FALLBACK_LIBRARY_PATH dans le shell sur OSX 10.11.1

Dans les scripts shell utilisés pour les tests unitaires avec les bibliothèques dynamiques dans un répertoire autre que le @rpath typique, j'ai déjà pu définir DYLD_FALLBACK_LIBRARY_PATH pour définir le répertoire contenant les bibliothèques. Sous 10.11.1, bash semble ignorer les tentatives de définition de cette variable d'environnement:

$ sh -x testscript.sh
+ DYLD_FALLBACK_LIBRARY_PATH=/Users/something/testinglibs
+ export DYLD_FALLBACK_LIBRARY_PATH
+ exec printenv

et DYLD_FALLBACK_LIBRARY_PATH n'est pas présent dans la sortie de printenv.

Est-ce un hack lié à la sécurité dans le shell de 10.11? Je n'ai pas pu trouver cette modification documentée dans les pages de manuel ou en ligne.

— Gars
source

L' outil install_name_tool aiderait-il?

— Saaru Lindestøkke

Bien sûr, install_name_tool est une solution permanente (et je l'ai en fait scriptée pour configurer l'environnement de construction). Pour des tests et un débogage rapides dans un environnement de développement, il est difficile de faire des copies temporaires des bibliothèques, de pirater les modifications de @rpath, puis d'oublier éventuellement la modification manuelle. DYLD_FALLBACK_LIBRARY_PATH et DYLD_LIBRARY_PATH étaient pratiques pour ces cycles de dev / test occasionnels.

— Guy

Il s'agit de la protection de l'intégrité du système introduite dans El Capitan

La documentation est dans ce d'Apple

Fondamentalement, tous les exécutables OS X fournis par Apple sont protégés. et (à partir d'un document antérieur)

La génération de processus enfants de processus restreints par la protection de l'intégrité du système, par exemple en lançant un processus d'assistance dans un ensemble avec NSTask ou en appelant la commande exec (2), réinitialise les ports spéciaux Mach de ce processus enfant. Toutes les variables d'environnement de l'éditeur de liens dynamiques (dyld), telles que DYLD_LIBRARY_PATH, sont purgées lors du lancement des processus protégés.

Dans ce cas, sh est protégé

— user151019
source

Merci pour le pointeur! J'étais concentré sur le noyau et les autres protections du système de fichiers dans SIP. N'a pas remarqué ce changement.

— Guy

Ok, cela explique l'origine du phénomène, mais comment diable sommes-nous maintenant censés tester les bibliothèques non installées? Je veux dire, comment pouvons-nous écrire make checksur El Capitan lorsque des bibliothèques partagées sont nécessaires?

— akim

La plupart des make via autoconf devraient se retrouver dans / usr / local qui est toujours accessible en écriture - s'ils essaient ailleurs sous / usr, je remettrais en question les connaissances de l'auteur sur OS X (ou Unix)

— user151019

Si quelqu'un trouve cela après avoir perdu du temps à essayer de comprendre pourquoi les variables d'environnement dyld disparaissaient, envisagez de déposer un bogue auprès d'Apple pour leur faire documenter l'interaction dyld / SIP. Je l'ai déjà fait, et le bogue a obtenu le numéro rdar: // 30755019. (J'espère qu'ils penseront alors à documenter d'autres pièges de ce genre ...)

— hmijail pleure les démissionnaires le

(Je voulais dire documenter l'interaction SIP dans la page dyld, qui de cette écriture est totalement maman à ce sujet)

— hmijail Mourns resignees