El Capitan, verifique, DYLD_LIBRARY_PATH

Desenvolvo aplicativos usando o conjunto de ferramentas Unix usual: um compilador makee bibliotecas compartilhadas. O procedimento é tradicionalmente algo como

• ./configure, que adapta as fontes para os recursos da máquina em que é executada,
• make, que na verdade compila as bibliotecas compartilhadas, executáveis ​​etc.,
• make check, que executa os testes antes de instalar o pacote,
• make install, se o pacote se comportar corretamente e, finalmente, opcionalmente,
• make installcheck, para garantir que a instalação funcione.

Durante make, as bibliotecas e executáveis ​​compartilhados são compilados em sua forma final: os executáveis ​​são compilados com uma dependência das bibliotecas compartilhadas em seu destino final (ou seja, eles dependem das bibliotecas, /usr/local/libembora ainda não existam, ainda estão em construção. árvore). Então make install, basicamente, é apenas o uso cppara instalar libs e executáveis ​​da árvore de construção até o local final.

Durante a make checkfase, estamos executando o programa desinstalado: as bibliotecas compartilhadas, executáveis ​​e arquivos auxiliares ainda estão na árvore de compilação. Para executar os testes, você precisa configurar algumas variáveis ​​de ambiente personalizadas (por exemplo, para informar ao seu programa que seus arquivos de dados auxiliares não estão na /usr/local/shareárvore de origem, mas) e algumas variáveis ​​de ambiente do sistema para informar ao seu load lib loader para as bibliotecas compartilhadas. As variáveis ​​de ambiente nos Unices tradicionais são LD_LIBRARY_PATH, no OS X, são DYLD_LIBRARY_PATH. Isso funcionou por (dezenas de) anos.

Mas agora, El Capitan quebrou isso.

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

agora, quando o SIP está ativado, nenhum DYLD_*é exportado de um processo para seus filhos.

Então, minha pergunta é: como podemos executar programas que não estão instalados? Qual é o procedimento a seguir para poder executar a sequência tradicional do Unix ./configure && make && make check?

Por favor , nenhuma resposta como "corra make installprimeiro". Essa não é a questão. Sou desenvolvedor, e executar "make check" (e, geralmente, executar uma versão não instalada de um programa) é algo que faço com muita frequência. Mesmo a instalação em um local falso é demorada. Eu preciso de algo eficaz e eficiente. Desabilitar o SIP não resolverá o problema dos usuários dos meus pacotes que desejam executar make check.

Parece que o DYLD_ * é removido apenas para binários "protegidos" (não sei exatamente o que isso significa, mas aparentemente qualquer coisa em / bin e / usr / bin para iniciantes) No entanto, se você copiar / usr / bin / env para outro lugar, ele mantém seu material DYLD_ *:

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

Eu acho que o make sempre executa comandos via / bin / sh, então você não pode definir variáveis ​​"perigosas" no makefile e fazê-las afetar os comandos, mas talvez você possa mover o teste para um shell script, definir as variáveis ​​de ambiente dentro do arquivo script e, em seguida, chame o script de make. Embora, obviamente, isso não o ajude se os testes, por sua vez, se basearem em scripts de shell (ou se as coisas testadas forem scripts de shell!), Porque eles invocam / bin / sh e perdem as variáveis ​​novamente .. .