El Capitan, verifica, DYLD_LIBRARY_PATH

9

Sviluppo applicazioni utilizzando il consueto set di strumenti Unix: un compilatore, make e librerie condivise. La procedura è quindi tradizionalmente simile a

  • ./configure , che adatta i sorgenti per le funzionalità della macchina su cui viene eseguito,
  • make , che in realtà compila le librerie condivise, i file eseguibili, ecc.
  • make check , che esegue i test prima installiamo 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 condivise e gli eseguibili sono compilati nella loro forma finale: gli eseguibili sono compilati con una dipendenza dalle librerie condivise nella loro destinazione finale (cioè dipendono dalle librerie in /usr/local/lib sebbene non siano c'è ancora, sono ancora nell'albero delle costruzioni). Quindi make install è, approssimativamente, usando solo cp per installare libs ed eseguibili dalla struttura ad albero fino alla posizione finale.

Durante la fase make check , stiamo eseguendo il programma disinstallato: le librerie, i file eseguibili e i file ausiliari condivisi sono ancora nella struttura di build. Per eseguire i test devi configurare alcune variabili di ambiente personalizzate (ad esempio per dire al tuo programma che i tuoi file di dati ausiliari non sono in /usr/local/share ma nell'albero dei sorgenti), e alcune variabili di ambiente di sistema, per dire al tuo share lib loader per cercare le librerie condivise. Le variabili di ambiente sugli Unices tradizionali sono LD_LIBRARY_PATH , su OS X è 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, nessun 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 essere in grado di eseguire la tradizionale sequenza Unix ./configure && make && make check ?

Prego , nessuna risposta come "esegui make install prima". Non è questo il punto. Sono uno sviluppatore, e l'esecuzione di "make check" (e più in generale l'esecuzione di una versione non installata di un programma) è qualcosa che faccio molto spesso. Anche l'installazione in un posto fittizio richiede molto tempo. Ho bisogno di qualcosa di efficace, e efficiente. E disabilitare SIP non risolverà il problema per gli utenti dei miei pacchetti che vogliono eseguire make check .

    
posta akim 10.11.2015 - 08:24
fonte

1 risposta

5

Sembra che DYLD_ * venga eliminato solo per i binari "protetti" (non sono sicuro di cosa significhi, ma apparentemente qualsiasi cosa in / bin e / usr / bin per gli avviatori) Tuttavia, se copi / usr / bin / env da qualche altra parte, mantiene 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 via / bin / sh, quindi non puoi impostare variabili "pericolose" nel makefile e far sì che influenzino i comandi, ma forse potresti spostare il test in uno script di shell, impostare l'ambiente variabili all'interno dello script e quindi richiamare 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 perdere di nuovo le variabili ...

    
risposta data 23.11.2015 - 09:49
fonte

Leggi altre domande sui tag