2012-03-29 8 views

Odpowiedz

57

Nie jestem pewien, czy istnieje opcja drukowania po prostu pełnej efektywnej ścieżki wyszukiwania.

Ale: ścieżka wyszukiwania składa się z katalogów określonych przez -L opcji w linii poleceń, a następnie katalogów dodanych do ścieżki wyszukiwania przez dyrektywy SEARCH_DIR("...") w skrypcie linkera. Więc można się dogadać, jeśli można zobaczyć zarówno tych, które można zrobić w następujący sposób:

Jeśli powołując ld bezpośrednio:

  • The -L opcji są co pan powiedział, że są .
  • Aby wyświetlić skrypt linkera, dodaj opcję --verbose. Poszukaj dyrektyw SEARCH_DIR("..."), zwykle w górnej części wyjścia. (Zauważ, że te niekoniecznie są takie same dla wszystkich wezwaniem ld - łącznik ma wiele różnych wbudowanych domyślnych skryptów linkera i wybiera między nimi w oparciu o różne inne opcje linkera.)

Jeśli „re łączenie poprzez gcc:

  • można przekazać opcję gcc-v tak, że pokazuje, jak to wywołuje łącznik. W rzeczywistości zwykle nie wywołuje bezpośrednio, ale pośrednio, poprzez narzędzie o nazwie collect2 (które znajduje się w jednym z jego wewnętrznych katalogów), co z kolei wywołuje ld. To pokazuje, które opcje są używane.
  • Możesz dodać -Wl,--verbose do opcji gcc, aby przekazać --verbose do łącznika, aby zobaczyć skrypt linkera, jak opisano powyżej.
+1

Opcja --verbose dla łącznika zrobiła lewę. Bardzo pomocne! – Ari

+0

Starałem się, aby dowiedzieć się, gdzie linker szukał i nie znaleziono SEARCH_DIR w danych wyjściowych. Okazuje się, że gdy używałem '-T script', mój skrypt całkowicie zastąpił domyślny skrypt ld i wyglądał tylko tam, gdzie wskazałem. – thomasa88

56

W systemie Linux można użyć ldconfig, który utrzymuje konfigurację ld.so i cache, aby wydrukować przeszukiwanie katalogów przez ld.so z

ldconfig -v 2>/dev/null | grep -v ^$'\t' 

ldconfig -v wypisuje przeszukiwane katalogi przez łącznik (bez głównej zakładki) i wspólnych bibliotek znalezionych w tych katalogach (z wiodącą zakładką); grep otrzymuje katalogi. Na moim komputerze, ta linia wypisuje

/usr/lib64/atlas: 
/usr/lib/llvm: 
/usr/lib64/llvm: 
/usr/lib64/mysql: 
/usr/lib64/nvidia: 
/usr/lib64/tracker-0.12: 
/usr/lib/wine: 
/usr/lib64/wine: 
/usr/lib64/xulrunner-2: 
/lib: 
/lib64: 
/usr/lib: 
/usr/lib64: 
/usr/lib64/nvidia/tls: (hwcap: 0x8000000000000000) 
/lib/i686: (hwcap: 0x0008000000000000) 
/lib64/tls: (hwcap: 0x8000000000000000) 
/usr/lib/sse2: (hwcap: 0x0000000004000000) 
/usr/lib64/tls: (hwcap: 0x8000000000000000) 
/usr/lib64/sse2: (hwcap: 0x0000000004000000) 

Pierwsze ścieżki, bez hwcap w kolejce, albo są wbudowane lub odczytać z /etc/ld.so.conf. Łącznik może następnie przeszukiwać dodatkowe katalogi pod podstawową ścieżką przeszukiwania biblioteki o nazwach takich jak sse2, odpowiadających dodatkowym możliwościom procesora. Te ścieżki, z hwcap w linii, mogą zawierać dodatkowe biblioteki dostosowane do tych możliwości procesora.

Ostatnia uwaga: zamiast tego używa się -p zamiast -v przeszukując pamięć podręczną ld.so.

+0

to działa, ale tylko wtedy, gdy jestem administratorem. –

+35

Pyta o linker (ld), a nie program ładujący (ld.so)! – fons

+3

Jak to jest możliwe, że jeśli ustawię 'export LD_LIBRARY_PATH =/some/other/dir', to nie wpłynie to na wynik tego polecenia ?! Wydaje się, że to nie działa w 100%? – TMS

48

Można to zrobić wykonując następujące polecenia:

ld --verbose | grep SEARCH_DIR | tr -s ' ;' \\012 

gcc przechodzi kilka dodatkowych -L ścieżki do łącznika, który możesz wymienić za pomocą następującego polecenia:

gcc -print-search-dirs | sed '/^lib/b 1;d;:1;s,/[^/.][^/]*/\.\./,/,;t 1;s,:[^=]*=,:;,;s,;,; ,g' | tr \; \\012 

Odpowiedzi sugerujące użycie ld.so.conf i ldconfig są niepoprawne, ponieważ odnoszą się do ścieżek wyszukanych przez dynamiczny linker środowiska wykonawczego (tj. Gdy program jest wykonywany), który nie jest tym samym, co ścieżka przeszukiwana przez ld (tj. kiedykolwiek program jest połączony).

+1

Trafiłeś w miejsce. Mam problem z łączeniem, podczas linkowania linker odnajduje ręcznie zainstalowane biblioteki w '/ usr/local/..', które powodują brak błędu biblioteki, a łączenie kończy się niepowodzeniem. Muszę zmienić nazwę '/ usr/local' za każdym razem, aby wykluczyć tę ścieżkę wyszukiwania. Czy istnieje prosty sposób na wykluczenie lub przesłonięcie ścieżki '/ usr/local'? – kenn

+0

Możesz spróbować ręcznie określić ścieżki biblioteki za pomocą opcji -L do GCC, co moim zdaniem (nie jestem pewien) zastąpi ścieżki biblioteki systemowej. Możesz także spróbować ustawić zmienną env LIBRARY_PATH przed kompilacją: $ LIBRARY_PATH =/somedir/gcc ... – faken

+1

Znam to łączenie w kompilacji z wiersza poleceń. Miałem na myśli globalny sposób na przesłonięcie ścieżki wyszukiwania 'ld'. Na przykład czasami muszę skompilować kod źródłowy z 'makefile' lub generować plik Makefile ze skryptu' configure' lub '' CMakeLists.txt' lub nawet bardziej skomplikowane, takie jak 'vala' lub' srt'. Trudno jest mi zmienić ścieżkę wyszukiwania 'ld' w takich przypadkach. – kenn

5

Pytanie jest oznaczone jako Linux, ale może to działa również pod Linuksem?

gcc -Xlinker -v 

W systemie Mac OS X, to drukuje:

@(#)PROGRAM:ld PROJECT:ld64-224.1 
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 armv6m armv7m armv7em 
Library search paths: 
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib 
Framework search paths: 
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/ 
[...] 

Opcja -Xlinker z gcc powyżej właśnie przechodzi -v do ld. Jednak:

ld -v 

nie drukuje ścieżki wyszukiwania.

+0

W systemie Linux drukuje również katalogi, ale w postaci '-Lpath'. Tak więc odpowiedź @ Raphaëla Londeixa jest lepsza. – pevik

15

najbardziej kompatybilny komenda Znalazłem dla gcc i brzękiem na Linuksie (dzięki armando.sano):

$ gcc -m64 -Xlinker --verbose 2>/dev/null | grep SEARCH | sed 's/SEARCH_DIR("=\?\([^"]\+\)"); */\1\n/g' | grep -vE '^$' 

jeśli dasz -m32, to wyświetli odpowiednie katalogi biblioteczne.

Przykłady na moim komputerze:

dla g++ -m64:

/usr/x86_64-linux-gnu/lib64 
/usr/i686-linux-gnu/lib64 
/usr/local/lib/x86_64-linux-gnu 
/usr/local/lib64 
/lib/x86_64-linux-gnu 
/lib64 
/usr/lib/x86_64-linux-gnu 
/usr/lib64 
/usr/local/lib 
/lib 
/usr/lib 

dla g++ -m32:

/usr/i686-linux-gnu/lib32 
/usr/local/lib32 
/lib32 
/usr/lib32 
/usr/local/lib/i386-linux-gnu 
/usr/local/lib 
/lib/i386-linux-gnu 
/lib 
/usr/lib/i386-linux-gnu 
/usr/lib 
+0

Dziękujemy! malusieńki - pozbyć się grep lub dwóch: sed -n 's/SEARCH_DIR ("= \? \ ([^"] \ + \) "); */\ 1 \ n/gp' –

1

wersja Mac: $ ld -v 2, nie wiem, jak uzyskać szczegółowe ścieżki. wyjście

Library search paths: 
    /usr/lib 
    /usr/local/lib 
Framework search paths: 
    /Library/Frameworks/ 
    /System/Library/Frameworks/ 
+1

Otrzymuję" nie można otworzyć 2: brak takiego pliku lub katalogu. "Uruchomienie' ld -v 2' – Jack

+0

Pytanie jest oznaczone jako Linux, nie OS X. Nie wierzę, że OS X używa GNU 'ld'. Ludzie Binutil wyłączyli go w kompilacji skrypty. Od lat jest wyłączona. – jww

Powiązane problemy