Difference between -pthread and -lpthread while compiling

Question

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

Attorn

Possible duplicate of Significance of -pthread flag when compiling – Eleaseeleatic

Answer 1

-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.

Colleencollege

Which is weird because it directly contradicts POSIX. POSIX mandates that passing -lpthread is enough to get the whole POSIX threading library. – Standard

@FUZxxl Passing -lpthread does get the whole POSIX threading library. – Casmey

@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. – Standard

@fuz: POSIX.1-2008 states that -l pthread "(...) shall make available all interfaces referenced in <pthread.h> and pthread_kill() and pthread_sigmask() referenced in <signal.h>. An implementation may search this library in the absence of this option." Nothing wrong with GCC. – Romanticism

@Romanticism 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. – Standard

@fuz: The point is that all interfaces referenced in <pthread.h> 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. – Romanticism

@Romanticism 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. – Standard

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]. – Mehalek

Regarding -mthread, does it use win32threads or does it just makes POSIX threads work for MinGW-w64? – Horribly

@HashimAziz There is no native POSIX Pthreads API in native Windows API. -mthreads documentation 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. – Exudation

Answer 2

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.

Exudation

Answer 3

-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.

Bulbous