156

What is the difference between gcc -pthread and gcc -lpthread which is used while compiling multithreaded programs?

RzR
  • 3,068
  • 29
  • 26
Vishnuraj V
  • 2,819
  • 3
  • 19
  • 23
  • 2
    Possible duplicate of [Significance of -pthread flag when compiling](https://stackoverflow.com/questions/2127797/gcc-significance-of-pthread-flag-when-compiling) – jww Aug 31 '17 at 13:43

3 Answers3

159

-pthread tells the compiler to link in the pthread library as well as configure the compilation for threads.

For example, the following shows the macros that get defined when the -pthread option gets used on the GCC package installed on my Ubuntu machine:

$ 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

Using the -lpthread option only causes the pthread library to be linked - the pre-defined macros don't get defined.

Bottom line: you should use the -pthread option.

Note: the -pthread option is documented as a platform specific option in the GCC docs, so it might not always be available. However, it is available on platforms that the GCC docs don't explicitly list it for (such as i386 and x86-64) - you should use it when available.

Also note that other similar options have been used by GCC, such as -pthreads (listed as a synonym for -pthread on Solaris 2) and -mthread (for MinGW-specific thread support on i386 and x86-64 Windows). My understanding is that GCC is trying to move to using -pthread uniformly going forward.

Michael Burr
  • 333,147
  • 50
  • 533
  • 760
  • 4
    Which is weird because it directly contradicts POSIX. POSIX mandates that passing `-lpthread` is enough to get the whole POSIX threading library. – fuz Jan 30 '16 at 14:11
  • 1
    @FUZxxl Passing `-lpthread` *does* get the whole POSIX threading library. – user253751 Feb 21 '16 at 22:15
  • 7
    @immibis No, what I mean is, POSIX says that linking with `-lpthread` should be enough to get full pthreads support. No other compilation flags should be needed. – fuz Feb 21 '16 at 22:17
  • @fuz: POSIX.1-2008 states that `-l pthread` "(...) shall make available all interfaces referenced in and pthread_kill() and pthread_sigmask() referenced in . **An implementation may search this library in the absence of this option.**" Nothing wrong with GCC. – alecov Mar 08 '18 at 15:35
  • 1
    @alecov What is wrong with gcc is that compiling with `-lpthread` but not `-pthread` is insufficient to get pthread support, as I already clarified in my previous comment. – fuz Mar 08 '18 at 15:47
  • @fuz: The point is that all interfaces referenced in `` et al _are_ made available, and the pthread library _is_ searched with `-pthread`. This meets the definition of "may search this library in the absence of this option (`-lpthread`)". No further requirement is made by POSIX, nor further "pthread support" defined either. – alecov Mar 08 '18 at 16:07
  • 3
    @alecov POSIX mandates that pthreads must work if you configure a POSIX environment and link with `-lpthread`. However, the gcc documentation suggests that this might be insufficient to get pthreads support, which is the point I made through the previous comments. I don't care at all about what happens if you don't provide `-lpthread` or some random other proprietary options. Only `-lpthread` is specified by POSIX to guarantee pthreads and that doesn't seems to be sufficient with gcc. – fuz Mar 08 '18 at 16:44
  • With clang, and `-lpthread`, we get the message: `clang-7: warning: -lpthread: 'linker' input unused [-Wunused-command-line-argument]`. Perhaps it would be better with `warning: -pthread: 'deprecated flag ignored [-Wunused-command-line-argument]`. – user2023370 May 31 '18 at 20:58
  • Regarding `-mthread`, does it use win32threads or does it just makes POSIX threads work for MinGW-w64? – Hashim Aziz Mar 18 '19 at 02:41
  • @HashimAziz There is no native POSIX Pthreads API in native Windows API. [-mthreads documentation](https://gcc.gnu.org/onlinedocs/gcc/x86-Windows-Options.html#index-mthreads-1) says: "_It specifies that MinGW-specific thread support is to be used._" and no further specs or guarantees. You may like to have a look at [WSL2](https://learn.microsoft.com/en-us/windows/wsl/compare-versions). – Maxim Egorushkin Nov 04 '21 at 20:36
43

There is an accepted answer, but, IMO, it doesn't provide enough context and insight. Hence this extra answer.

-lpthread is a solution for a problem that no longer exists (since ~2005).

In the old days there were proprietary implementations of Pthreads API that weren't POSIX-compliant, like LinuxThreads. POSIX standard merely says that if one wants POSIX-compliant behaviour, then one must link with -lpthread, and linking that is required to link a POSIX-compliant implementation of Pthreads API, should there be multiple implementations of it.

There are no multiple implementations of Pthreads API in modern operating systems. And that is why -lpthread no longer serves any purpose.

Compilers like gcc and clang (and, probably, all Linux-compatible compilers) require using -pthread command line option for both compiling and linking POSIX-compliant multi-threaded applications and that is what one must use.

Compiler's documentation is the ultimate authoritive source, any diverging 3rd-party documentation is rather irrelevant.

At compile time, -pthread option manifests that Pthread API is requested (there can be multiple threading APIs, e.g. Solaris Threads) and defines platform-specific macros (_REENTRANT on Linux, _MT on Solaris).

At link time, -pthread links in required libraries (if any) that implement POSIX-compliant Pthreads API behaviour.

The above makes it clear why -lpthread is neither necessary nor sufficient.

GNU libc 2.34:

New applications do not need to link with -lpthread, -ldl, -lutil, -lanl anymore. For backwards compatibility, empty static archives libpthread.a, libdl.a, libutil.a, libanl.a are provided, so that the linker options keep working. Applications which have been linked against glibc 2.33 or earlier continue to load the corresponding shared objects (which are now empty).

More info in Why glibc 2.34 removed libpthread.

Maxim Egorushkin
  • 131,725
  • 17
  • 180
  • 271
18

-pthread Adds support for multithreading with the pthreads library. This option sets flags for both the preprocessor and linker (man gcc).

while

-lpthread comes in existence while linking there will be no influence while preprocessing.

Praveen Kumar
  • 191
  • 1
  • 6