Não foi possível definir DYLD_FALLBACK_LIBRARY

Nos scripts de shell usados para teste de unidade com bibliotecas dinâmicas em um diretório que não seja o típico @rpath, anteriormente eu pude definir DYLD_FALLBACK_LIBRARY_PATH para definir o diretório que contém as bibliotecas. Sob 10.11.1, o bash parece ignorar as tentativas de definir essa variável de ambiente:

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

e DYLD_FALLBACK_LIBRARY_PATH não está presente na saída do printenv.

Este é um hack relacionado à segurança no shell do 10.11? Não consegui encontrar essa alteração documentada nas páginas de manual ou online.

— Cara
fonte

O install_name_tool ajudaria?

— Saaru Lindestøkke 28/02

Claro, install_name_tool é uma solução permanente (e eu a escrevi para configurar o ambiente de construção). Para testes e depuração rápidos em um ambiente de desenvolvimento, é um trabalho complicado fazer cópias temporárias de bibliotecas, invadir as alterações do @rpath e, em seguida, esquecer a alteração manual. DYLD_FALLBACK_LIBRARY_PATH e DYLD_LIBRARY_PATH foram úteis para esses ciclos ocasionais de desenvolvimento / teste.

— Guy

Esta é a Proteção de Integridade do Sistema introduzida no El Capitan

A documentação está presente na Apple

Basicamente, todos os executáveis do OS X fornecidos pela Apple são protegidos. e (de um documento anterior)

Gerar processos filhos de processos restritos pelo System Integrity Protection, como iniciar um processo auxiliar em um pacote com o NSTask ou chamar o comando exec (2), redefine as portas especiais do Mach desse processo filho. Quaisquer variáveis de ambiente do vinculador dinâmico (dyld), como DYLD_LIBRARY_PATH, são eliminadas ao iniciar processos protegidos.

Neste caso, sh está protegido

— user151019
fonte

Obrigado pelo ponteiro! Eu estava focado no kernel e em outras proteções do sistema de arquivos no SIP. Não percebeu essa alteração.

— Guy

Ok, isso explica a origem do fenômeno, mas como diabos devemos agora testar bibliotecas não instaladas? Quero dizer, como podemos escrever make checkno El Capitan quando são necessárias bibliotecas compartilhadas?

— akim

A maioria make via autoconf deve acabar em / usr / local, que ainda é gravável - se eles tentarem para qualquer outro lugar em / usr eu iria questionar o conhecimento do autor do OS X (ou Unix)

— user151019

Se alguém descobrir isso depois de perder tempo tentando entender por que os vários ambientes do dyld estavam desaparecendo, considere registrar um bug na Apple para fazê-los documentar a interação dyld / SIP. Eu já fiz, e o bug obteve o número rdar: // 30755019. (Espero que eles pensem em documentar outras armadilhas ...)

— hmijail lamenta os demitidos

(Eu quis dizer documentar a interação SIP na página de manual do dyld, que até o momento é totalmente

— obscura

Não foi possível definir DYLD_FALLBACK_LIBRARY_PATH no shell no OSX 10.11.1