El Capitán, verifique, DYLD_LIBRARY_PATH

9

Desarrollo aplicaciones utilizando el conjunto de herramientas de Unix habitual: un compilador, make y bibliotecas compartidas. El procedimiento es entonces tradicionalmente algo así como

  • ./configure , que adapta las fuentes para las características de la máquina en la que se ejecuta,
  • make , que en realidad compila las librerías compartidas, ejecutables, etc.,
  • make check , que ejecuta las pruebas antes instalamos 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 libs compartidas y los ejecutables se compilan en su forma final: los ejecutables se compilan con una dependencia de las libs compartidas en su destino final (es decir, dependen de las bibliotecas en /usr/local/lib aunque no lo son). aún allí, todavía están en el árbol de construcción). Luego, make install es, aproximadamente, solo usando cp para instalar libs y ejecutables desde el árbol de compilación hasta el lugar final.

Durante la fase make check , estamos ejecutando el programa desinstalado: las librerías compartidas, los archivos 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 informarle a su programa que sus archivos de datos auxiliares no están en /usr/local/share sino en el árbol de origen), y algunas variables de entorno del sistema, para informarle a su biblioteca de recursos compartidos cargador para buscar las libs compartidas. Las variables de entorno en Unices tradicionales son LD_LIBRARY_PATH , en OS X 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 se exporta DYLD_* de 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 respuesta como "ejecuta make install primero". 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 falso requiere mucho tiempo. Necesito algo efectivo, y eficiente. Y deshabilitar SIP no solucionará el problema para los usuarios de mis paquetes que desean ejecutar make check .

    
pregunta akim 10.11.2015 - 08:24

1 respuesta

5

Parece que DYLD_ * solo se elimina por binarios "protegidos" (no estoy seguro de lo que eso significa, pero aparentemente hay algo en / bin y / usr / bin para empezar) Sin embargo, si copia / usr / bin / env a otro lugar, puede mantener su contenido 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, configurar el entorno variables dentro del script, y luego invocar el script desde make. Aunque obviamente, esto no le ayudará si las pruebas, a su vez, dependen de los scripts de shell (o si las cosas probadas son scripts de shell) porque entonces van a invocar / bin / sh y perder las variables de nuevo ...

    
respondido por el Ture Pålsson 23.11.2015 - 09:49

Lea otras preguntas en las etiquetas