No se puede establecer DYLD_FALLBACK_LIBRARY_PATH en el shell en OSX 10.11.1

11

En los scripts de shell utilizados para las pruebas unitarias con bibliotecas dinámicas en un directorio que no sea el típico @rpath, anteriormente he podido configurar DYLD_FALLBACK_LIBRARY_PATH para establecer el directorio que contiene las bibliotecas. Bajo 10.11.1, bash parece ignorar los intentos de establecer esta variable de entorno:

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

y DYLD_FALLBACK_LIBRARY_PATH no está presente en la salida de printenv.

¿Es este un truco relacionado con la seguridad en el shell de 10.11? No he podido encontrar este cambio documentado en páginas de manual o en línea.

macos command-line bash environment-variables dynamic-library Chico
fuente
¿ Ayudaría install_name_tool ?
Saaru Lindestøkke
Claro, install_name_tool es una solución permanente (y de hecho lo he programado para configurar el entorno de compilación). Para realizar pruebas y depurar rápidamente en un entorno de desarrollo, es una molestia tener que hacer copias temporales de las bibliotecas, piratear los cambios de @rpath y luego posiblemente olvidarse del cambio manual. DYLD_FALLBACK_LIBRARY_PATH y DYLD_LIBRARY_PATH fueron útiles para estos ciclos ocasionales de desarrollo / prueba.
Guy

Respuestas:

8

Esta es la Protección de Integridad del Sistema introducida en El Capitan

La documentación está en esto de Apple

Básicamente, todos los ejecutables de OS X suministrados por Apple están protegidos. y (de un documento anterior)

Generar procesos hijos de procesos restringidos por la Protección de integridad del sistema, como iniciar un proceso auxiliar en un paquete con NSTask o llamar al comando exec (2), restablece los puertos especiales de Mach de ese proceso hijo. Cualquier variable de entorno del enlazador dinámico (dyld), como DYLD_LIBRARY_PATH, se purga al iniciar procesos protegidos.

En este caso sh está protegido

usuario151019
fuente
¡Gracias por la anotación! Me había centrado en el núcleo y otras protecciones del sistema de archivos en SIP. No noté este cambio.
Guy
2
Ok, esto explica el origen del fenómeno, pero ¿cómo diablos se supone que ahora debemos probar las bibliotecas no instaladas? Quiero decir, ¿cómo podemos escribir make checken El Capitán cuando se necesitan bibliotecas compartidas?
akim
La mayoría de make vía autoconf debería terminar en / usr / local, que todavía se puede escribir; si lo intentan en otro lugar bajo / usr, cuestionaría el conocimiento del autor sobre OS X (o Unix)
user151019
Si alguien encuentra esto después de perder el tiempo tratando de entender por qué los entornos dyld estaban desapareciendo, considere presentar un error con Apple para que documente la interacción dyld / SIP. Ya lo hice, y el error obtuvo el número rdar: // 30755019. (Espero que luego piensen en documentar otras trampas de este tipo ...)
hmijail llora a las personas designadas
1
(I decir documento la interacción SIP en la página del manual dyld, que a partir de este escrito es totalmente mamá sobre él)
Mourns hmijail resignees