El Capitan, sprawdź, DYLD_LIBRARY_PATH

Tworzę aplikacje przy użyciu zwykłego zestawu narzędzi Unix: kompilatora makei bibliotek współdzielonych. Procedura jest wtedy tradycyjnie podobna

• ./configure, który dostosowuje źródła funkcji komputera, na którym jest uruchomiony,
• make, który faktycznie kompiluje udostępnione biblioteki lib, pliki wykonywalne itp.,
• make check, który uruchamia testy przed zainstalowaniem pakietu,
• make install, jeśli pakiet zachowuje się poprawnie, a na koniec opcjonalnie
• make installcheck, aby upewnić się, że instalacja działa.

Podczas makewspółdzielonych bibliotek lib i plików wykonywalnych są kompilowane w ostatecznej formie: pliki wykonywalne są kompilowane w zależności od bibliotek współdzielonych w ich ostatecznym miejscu docelowym (tzn. Zależą od bibliotek, /usr/local/libmimo że jeszcze ich nie ma, wciąż są w kompilacji drzewo). Z make installgrubsza używa tylko cpbiblioteki lib i plików wykonywalnych z drzewa kompilacji do ostatecznego miejsca.

Podczas tej make checkfazy uruchamiamy odinstalowany program: współdzielone biblioteki lib, pliki wykonywalne i pliki pomocnicze są nadal w drzewie kompilacji. Aby uruchomić testy, musisz ustawić kilka niestandardowych zmiennych środowiskowych (na przykład, aby poinformować program, że twoich plików danych pomocniczych nie ma, /usr/local/shareale w drzewie źródłowym) oraz niektóre systemowe zmienne środowiskowe, aby Twój program ładujący bibliotekę współdzieloną szukał dla wspólnych bibliotek. Zmienne środowiskowe w tradycyjnych Unices są LD_LIBRARY_PATH, w OS X tak DYLD_LIBRARY_PATH. To działało przez (kilkadziesiąt) lat.

Ale teraz El Capitan to złamał.

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

teraz, gdy SIP jest włączony, żadne nie DYLD_*jest eksportowane z procesu do jego elementów podrzędnych.

Moje pytanie brzmi: w jaki sposób możemy uruchamiać programy, które nie są zainstalowane? Jaką procedurę należy wykonać, aby móc uruchomić tradycyjną sekwencję uniksową ./configure && make && make check?

Proszę , nie ma odpowiedzi takiej jak „ make installnajpierw uruchom ”. Nie o to chodzi. Jestem programistą, a wykonywanie polecenia „make check” (a bardziej ogólnie uruchamianie niezainstalowanej wersji programu) jest czymś, co robię bardzo często. Nawet instalacja w fałszywym miejscu jest czasochłonna. Potrzebuję czegoś skutecznego i wydajnego. A wyłączenie SIP nie rozwiąże problemu dla użytkowników moich pakietów, które chcą uruchomić make check.

Wygląda na to, że DYLD_ * jest usuwany tylko dla „chronionych” plików binarnych (nie jestem pewien, co to dokładnie oznacza, ale najwyraźniej cokolwiek w / bin i / usr / bin na początek) Jednak jeśli skopiujesz / usr / bin / env gdzie indziej, zachowuje swoje DYLD_ * rzeczy:

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

Myślę, że make zawsze uruchamia polecenia przez / bin / sh, więc nie możesz ustawić „niebezpiecznych” zmiennych w pliku makefile i mieć ich wpływ na polecenia, ale może możesz przenieść test do skryptu powłoki, ustawić zmienne środowiskowe wewnątrz skrypt, a następnie wywołaj skrypt z make. Oczywiście nie pomoże ci to, jeśli testy z kolei polegają na skryptach powłoki (lub jeśli testowane są skrypty powłoki!), Ponieważ wtedy wywołają / bin / sh i ponownie utracą zmienne ... .