Różnica między -pthread i -lpthread podczas kompilacji

Odpowiedzi:

116

-pthread informuje kompilator, aby połączyć się z biblioteką pthread, a także skonfigurować kompilację dla wątków.

Na przykład poniżej przedstawiono makra, które są definiowane, gdy -pthreadopcja zostanie użyta w pakiecie GCC zainstalowanym na moim komputerze z systemem Ubuntu:

$ gcc -pthread -E -dM test.c > dm.pthread.txt
$ gcc          -E -dM test.c > dm.nopthread.txt
$ diff dm.pthread.txt dm.nopthread.txt 
152d151
< #define _REENTRANT 1
208d206
< #define __USE_REENTRANT 1

Użycie tej -lpthreadopcji powoduje tylko połączenie biblioteki pthread - wstępnie zdefiniowane makra nie są definiowane.

Podsumowując: powinieneś skorzystać z tej -pthreadopcji.

Uwaga: -pthreadopcja jest udokumentowana jako opcja specyficzna dla platformy w dokumentacji GCC, więc nie zawsze może być dostępna. Jest jednak dostępny na platformach, dla których dokumentacja GCC nie podaje go wyraźnie (na przykład i386 i x86-64) - powinieneś go używać, gdy jest dostępny.

Zauważ również, że inne podobne opcje były używane przez GCC, takie jak -pthreads(wymienione jako synonim dla -pthreadw Solaris 2) i -mthread(dla obsługi wątków specyficznych dla MinGW w i386 i x86-64 Windows). Rozumiem, że GCC próbuje przejść na -pthreadjednolity rozwój.

Michael Burr
źródło
2
Co jest dziwne, ponieważ bezpośrednio zaprzecza POSIX. POSIX narzuca, że ​​przekazanie -lpthreadwystarczy, aby uzyskać całą bibliotekę wątków POSIX.
fuz
@FUZxxl Podania -lpthread nie dostać całą bibliotekę wątków POSIX.
user253751
5
@immibis Nie, mam na myśli to, że POSIX mówi, że linkowanie z -lpthreadpowinno wystarczyć, aby uzyskać pełną obsługę pthreads. Żadne inne flagi kompilacji nie powinny być potrzebne.
fuz
1
@alecov Problem z gcc polega na tym, że kompilacja z, -lpthreadale nie -pthreadjest wystarczająca, aby uzyskać obsługę pthread, jak już wyjaśniłem w moim poprzednim komentarzu.
fuz
2
@alecov POSIX nakazuje, że pthreads muszą działać, jeśli konfigurujesz środowisko POSIX i łączysz się z -lpthread. Jednak dokumentacja gcc sugeruje, że może to być niewystarczające do uzyskania obsługi pthreads, o czym pisałem w poprzednich komentarzach. W ogóle mnie nie obchodzi, co się stanie, jeśli nie podasz -lpthreadlub nie udostępnisz przypadkowych innych zastrzeżonych opcji. Tylko -lpthreadjest określony przez POSIX do pthreads gwarancyjnych i że nie wydaje się być wystarczająca z gcc.
fuz
10

-pthreadDodaje obsługę wielowątkowości z biblioteką pthreads. Ta opcja ustawia flagi zarówno dla preprocesora, jak i konsolidatora (man gcc ).

podczas

-lpthread istnieje podczas łączenia, nie będzie żadnego wpływu na przetwarzanie wstępne.

Praveen Kumar
źródło
4

Istnieje akceptowana odpowiedź, ale IMO nie zapewnia wystarczającego kontekstu i wglądu. Stąd ta dodatkowa odpowiedź.

-lpthread jest rozwiązaniem problemu, który już nie istnieje (od ~ 2005 roku).

W dawnych czasach istniały zastrzeżone implementacje API Pthreads , które nie były zgodne z POSIX, jak LinuxThreads . Standard POSIX mówi po prostu, że jeśli ktoś chce zachowania zgodnego z POSIX, to musi łączyć się z -lpthreadimplementacją API Pthreads zgodną z POSIX i linkować , które jest wymagane, jeśli istnieje wiele jej implementacji .

W nowoczesnych systemach operacyjnych nie ma wielu implementacji API Pthreads. I dlatego -lpthreadnie służy już żadnemu celowi.

Kompilatory takie jak gcci clang(i prawdopodobnie wszystkie kompilatory kompatybilne z Linuksem) wymagają użycia -pthreadopcji wiersza poleceń zarówno do kompilowania, jak i łączenia zgodnych z POSIX aplikacji wielowątkowych i właśnie tego należy używać.

W czasie kompilacji -pthreadopcja pokazuje, że żądano API Pthread (może być wiele interfejsów API do obsługi wątków, np. Solaris Threads) i definiuje makra specyficzne dla platformy ( _REENTRANTw systemie Linux , w systemie_MT Solaris).

W czasie -pthreaddowiązania łącza w wymaganych bibliotekach (jeśli istnieją), które implementują zachowanie interfejsu API Pthreads zgodne z POSIX.

Powyższe wyjaśnia, dlaczego -lpthreadnie jest to ani konieczne, ani wystarczające.

Maxim Egorushkin
źródło