El Capitan, haga el cheque, DYLD_LIBRARY_PATH

Desarrollo aplicaciones usando el conjunto de herramientas de Unix habitual: un compilador makey bibliotecas compartidas. El procedimiento es tradicionalmente algo así como

• ./configure, que adapta las fuentes para las características de la máquina en la que se ejecuta,
• make, que realmente compila las bibliotecas compartidas, los ejecutables, etc.,
• make check, que ejecuta las pruebas antes de instalar el paquete,
• make install, si el paquete se comporta correctamente y, finalmente, opcionalmente,
• make installcheck, para asegurarse de que la instalación funciona.

Durante make, las bibliotecas y los ejecutables compartidos se compilan en su forma final: los ejecutables se compilan con una dependencia de las bibliotecas compartidas en su destino final (es decir, dependen de las bibliotecas /usr/local/libaunque aún no están allí, todavía están en la compilación árbol). Luego make install, más o menos, solo se usa cppara instalar libs y ejecutables desde el árbol de compilación hasta el lugar final.

Durante la make checkfase, estamos ejecutando el programa desinstalado: las bibliotecas compartidas, los ejecutables y los archivos auxiliares todavía están en el árbol de compilación. Para ejecutar las pruebas, debe configurar algunas variables de entorno personalizadas (por ejemplo, para decirle a su programa que sus archivos de datos auxiliares no están /usr/local/shareen el árbol de origen sino en él), y algunas variables de entorno del sistema, para indicarle al cargador de lib compartido que busque para las bibliotecas compartidas. Las variables de entorno en Unices tradicionales son LD_LIBRARY_PATH, en OS X lo es DYLD_LIBRARY_PATH. Esto ha funcionado durante (docenas de) años.

Pero ahora, El Capitán rompió esto.

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

ahora, cuando SIP está habilitado, no DYLD_*se exporta un proceso a sus hijos.

Entonces mi pregunta es: ¿Cómo podemos ejecutar programas que no están instalados? ¿Cuál es el procedimiento a seguir para poder ejecutar la secuencia tradicional de Unix ./configure && make && make check?

Por favor , no hay respuestas como "corre make installprimero". Ese no es el punto. Soy un desarrollador, y ejecutar "make check" (y, en general, ejecutar una versión no instalada de un programa) es algo que hago con mucha frecuencia. Incluso la instalación en un lugar ficticio lleva mucho tiempo. Necesito algo efectivo y eficiente. Y deshabilitar SIP no solucionará el problema para los usuarios de mis paquetes que quieran ejecutarse make check.

Parece que DYLD_ * solo se elimina para los binarios "protegidos" (no estoy seguro de lo que eso significa, pero aparentemente cualquier cosa en / bin y / usr / bin para empezar) Sin embargo, si copia / usr / bin / env a otro lugar, puede mantener sus cosas DYLD_ *:

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

Creo que make siempre ejecuta comandos a través de / bin / sh, por lo que no puede establecer variables "peligrosas" en el archivo MAKE y hacer que afecten a los comandos, pero tal vez podría mover la prueba a un script de shell, establecer las variables de entorno dentro del script y luego invoque el script desde make. Aunque obviamente, esto no lo ayudará si las pruebas, a su vez, se basan en scripts de shell (¡o si las cosas probadas son scripts de shell!) Porque entonces invocarán / bin / sh y perderán las variables nuevamente ... .