El Capitan, controlla, DYLD_LIBRARY_PATH

Sviluppo applicazioni usando il solito set di strumenti Unix: un compilatore makee librerie condivise. La procedura è quindi tradizionalmente qualcosa di simile

• ./configure, che adatta le fonti per le caratteristiche della macchina su cui è in esecuzione,
• make, che in realtà compila le librerie condivise, gli eseguibili, ecc.,
• make check, che esegue i test prima di installare il pacchetto,
• make install, se il pacchetto si comporta correttamente e infine, facoltativamente,
• make installcheck, per assicurarsi che l'installazione funzioni.

Durante make, le librerie e gli eseguibili condivisi sono compilati nella loro forma finale: gli eseguibili sono compilati con una dipendenza dalle librerie condivise nella loro destinazione finale (cioè, dipendono dalle librerie /usr/local/libanche se non sono ancora lì, sono ancora nella build albero). Quindi make install, all'incirca, usa solo cpper installare librerie ed eseguibili dall'albero della build nella posizione finale.

Durante la make checkfase, stiamo eseguendo il programma disinstallato: le librerie condivise, i file eseguibili e i file ausiliari sono ancora nell'albero della build. Per eseguire i test devi impostare alcune variabili d'ambiente personalizzate (ad esempio per dire al tuo programma che i tuoi file di dati ausiliari non sono presenti /usr/local/sharema nell'albero dei sorgenti) e alcune variabili d'ambiente di sistema, per dire al tuo caricatore di lib libere di guardare per le librerie condivise. Le variabili di ambiente su Unices tradizionali sono LD_LIBRARY_PATH, su OS X lo è DYLD_LIBRARY_PATH. Questo ha funzionato per (dozzine di) anni.

Ma ora El Capitan ha rotto questo.

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

ora, quando SIP è abilitato, no DYLD_*viene esportato da un processo ai suoi figli.

Quindi la mia domanda è: come possiamo eseguire programmi che non sono installati? Qual è la procedura da seguire per poter eseguire la tradizionale sequenza Unix ./configure && make && make check?

Per favore , nessuna risposta come "esegui make installprima". Non è questo il punto. Sono uno sviluppatore e eseguire "make check" (e più in generale eseguendo una versione non installata di un programma) è qualcosa che faccio molto frequentemente. Anche l'installazione in un luogo fittizio richiede tempo. Ho bisogno di qualcosa di efficace ed efficiente. E la disabilitazione di SIP non risolverà il problema per gli utenti dei miei pacchetti che vogliono eseguire make check.

Sembra che DYLD_ * venga rimosso solo per i binari "protetti" (non sono sicuro esattamente cosa significhi, ma apparentemente qualsiasi cosa in / bin e / usr / bin per i principianti) Tuttavia, se copi / usr / bin / env da qualche altra parte, riesce a mantenere la sua roba DYLD_ *:

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

Penso che make esegua sempre i comandi tramite / bin / sh, quindi non è possibile impostare variabili "pericolose" nel makefile e farle influenzare i comandi, ma forse è possibile spostare il test in uno script di shell, impostare le variabili di ambiente all'interno del script, quindi invoca lo script da make. Anche se ovviamente, questo non ti aiuterà se i test, a loro volta, si basano su script di shell (o se le cose testate sono script di shell!) Perché poi invocheranno / bin / sh e perderanno di nuovo le variabili .. .