Эль-Капитан, проверь, DYLD_LIBRARY_PATH

Я разрабатываю приложения, используя обычный набор инструментов Unix: компилятор makeи разделяемые библиотеки. Процедура тогда традиционно что-то вроде

• ./configure, который настраивает источники для особенностей машины, на которой он работает,
• make, который на самом деле компилирует общие библиотеки, исполняемые файлы и т. д.,
• make check, который запускает тесты перед установкой пакета,
• make install, если пакет ведет себя правильно, и, наконец, при необходимости,
• make installcheck, чтобы убедиться, что установка работает.

Во makeвремя общих библиотек и исполняемых файлов скомпилированы в их окончательной форме: исполняемые файлы скомпилированы с зависимостью от общих библиотек в их конечном назначении (то есть, они зависят от библиотек, /usr/local/libхотя их еще нет, они все еще находятся в сборке дерево). Затем make install, грубо говоря, просто используется cpдля установки библиотек и исполняемых файлов из дерева сборки в конечное место.

На этом make checkэтапе мы запускаем деинсталлированную программу: общие библиотеки, исполняемые файлы и вспомогательные файлы все еще находятся в дереве сборки. Чтобы запустить тесты, вы должны установить несколько пользовательских переменных среды (например, чтобы сообщить вашей программе, что ваши вспомогательные файлы данных не находятся, /usr/local/shareно в дереве исходных текстов), и некоторые системные переменные среды, чтобы ваш загрузчик общих библиотек посмотрел для общих библиотек. Переменные окружения на традиционных Unices есть LD_LIBRARY_PATH, на OS X это так DYLD_LIBRARY_PATH. Это работало в течение (десятки) лет.

Но теперь El Capitan сломал это.

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

теперь, когда SIP включен, no DYLD_*экспортируется из процесса в его дочерние элементы.

Итак, мой вопрос: как мы можем запускать программы, которые не установлены? Какова процедура, чтобы следовать, чтобы иметь возможность запустить традиционную последовательность Unix ./configure && make && make check?

Пожалуйста , не отвечайте, например, «беги make installпервым». Не в этом дело. Я разработчик, и я часто запускаю команду «make check» (и, как правило, запускаю неустановленную версию программы). Даже установка в фиктивное место отнимает много времени. Мне нужно что-то эффективное и действенное. И отключение SIP не решит проблему для пользователей моих пакетов, которые хотят работать make check.

Кажется, что DYLD_ * удаляется только для «защищенных» двоичных файлов (я не уверен, что именно это означает, но, очевидно, что-нибудь в / bin и / usr / bin для начинающих) Однако, если вы копируете / usr / bin / env куда-то еще, он может сохранить свои вещи DYLD_ *:

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

Я думаю, что make всегда запускает команды через / bin / sh, поэтому вы не можете установить «опасные» переменные в make-файле и заставить их влиять на команды, но, возможно, вы можете переместить тест в сценарий оболочки, установить переменные среды внутри script, а затем вызовите скрипт из make. Хотя очевидно, что это не поможет вам, если тесты, в свою очередь, полагаются на сценарии оболочки (или если тестируемые объекты являются сценариями оболочки!), Потому что тогда они собираются вызвать / bin / sh и снова потерять переменные ... ,