Qual è la differenza tra gcc -pthreade gcc -lpthreadquale viene utilizzato durante la compilazione di programmi multithread?
Qual è la differenza tra gcc -pthreade gcc -lpthreadquale viene utilizzato durante la compilazione di programmi multithread?
Risposte:
-pthread dice al compilatore di collegarsi alla libreria pthread e di configurare la compilazione per i thread.
Ad esempio, quanto segue mostra le macro che vengono definite quando l' -pthreadopzione viene utilizzata sul pacchetto GCC installato sulla mia macchina 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
L'uso -lpthreaddell'opzione causa solo il collegamento della libreria pthread: le macro predefinite non vengono definite.
In conclusione: dovresti usare l' -pthreadopzione.
Nota: l' -pthreadopzione è documentata come opzione specifica della piattaforma nei documenti di GCC, quindi potrebbe non essere sempre disponibile. Tuttavia, è disponibile su piattaforme per le quali i documenti di GCC non lo elencano esplicitamente (come i386 e x86-64) - dovresti usarlo quando disponibile.
Notare inoltre che altre opzioni simili sono state utilizzate da GCC, come -pthreads(elencato come sinonimo di -pthreadsu Solaris 2) e -mthread(per il supporto dei thread specifico di MinGW su i386 e x86-64 Windows). La mia comprensione è che GCC sta cercando di passare all'uso in -pthreadmodo uniforme andando avanti.
-lpthreadsia sufficiente per ottenere l'intera libreria di threading POSIX.
-lpthread fa ottenere l'intera libreria di threading POSIX.
-lpthreaddovrebbe essere sufficiente per ottenere il pieno supporto di pthreads. Non dovrebbero essere necessari altri flag di compilazione.
-lpthreadma non -pthreadè insufficiente per ottenere il supporto di pthread, come ho già chiarito nel mio commento precedente.
-lpthread. Tuttavia, la documentazione di gcc suggerisce che ciò potrebbe essere insufficiente per ottenere il supporto di pthreads, che è il punto che ho sottolineato nei commenti precedenti. Non mi interessa affatto di cosa succede se non fornisci -lpthreado altre opzioni proprietarie casuali. Solo -lpthreadè specificato da POSIX per garantire pthread e questo non sembra essere sufficiente con gcc.
-pthreadAggiunge il supporto per il multithreading con la libreria pthreads. Questa opzione imposta i flag sia per il preprocessore che per il linker ( man gcc).
mentre
-lpthread viene creato durante il collegamento, non ci sarà alcuna influenza durante la pre-elaborazione.
C'è una risposta accettata, ma, IMO, non fornisce abbastanza contesto e intuizione. Da qui questa risposta in più.
-lpthread è una soluzione per un problema che non esiste più (dal ~ 2005).
Ai vecchi tempi c'erano implementazioni proprietarie dell'API Pthreads che non erano conformi a POSIX, come LinuxThreads . Lo standard POSIX dice semplicemente che se si vuole un comportamento conforme a POSIX, allora ci si deve collegare -lpthreade collegare che è richiesto per collegare un'implementazione conforme a POSIX dell'API Pthreads, se ci sono molte implementazioni di essa .
Non ci sono implementazioni multiple dell'API Pthreads nei sistemi operativi moderni. E questo è perché-lpthread non serve più a nessuno scopo.
I compilatori come gcce clang(e, probabilmente, tutti i compilatori compatibili con Linux) richiedono l' utilizzo di-pthread dell'opzione della riga di comando sia per la compilazione che per il collegamento di applicazioni multi-thread conformi a POSIX e questo è ciò che si deve usare.
In fase di compilazione, l' -pthreadopzione mostra che è richiesta l'API Pthread (possono essere presenti più API di threading, ad esempio Solaris Threads) e definisce le macro specifiche della piattaforma ( _REENTRANTsu Linux , _MTsu Solaris).
Al momento del collegamento, -pthreadcollegamenti nelle librerie richieste (se presenti) che implementano il comportamento dell'API Pthreads conforme a POSIX.
Quanto sopra chiarisce perché -lpthreadnon è né necessario né sufficiente.