GCC supports a -pthread option on several platforms, which causes the necessary options for using POSIX threads to be passed to the preprocessor, compiler and linker.
In particular, for GNU/Linux on x86 -pthread passes -D_REENTRANT to the preprocessor and -lpthread to the linker.
The documentation for GCC options doesn't currently mention -pthread except for a few specific architectures. The reasons for this are lengthy, but not very good.
On Solaris, GCC used to only support the -pthreads option, which is how Sun's compiler spells it, but in recent versions of GCC -pthread has the same effect.
(I might post other little-known GCC facts here, in the vain hope it will disseminate the information more widely.)
There is a noisy thread currently taking place on the GCC mailing list arguing over whether compiler optimisations that result in speculative loads are valid in multithreaded programs. Several people have made mistaken claims about guarantees made by POSIX (there are almost none) and others have argued from personal opinion. A few have argued from positions which are technically correct, but incompatible with the proposed C++ memory model. Very few of the participants seem to have bothered to read the link I first posted several days ago and aph re-posted yesterday: N2338: Concurrency memory model compiler consequences. When the authors of the proposed memory model take the time to spell out how the issues affect compilers, you'd hope people would read it before pontificating on that very subject.
The discusion has spilled over to LKML and (among others) Ian Lance Taylor's blag, which has been required reading for me since his series on linkers.
Unfortunately, despite all the apparent experts on the GCC list arguing about whether particular examples are valid without locks or memory barriers, noone seems interested in reviewing my patch to improve the use of memory barriers in GCC's shared_ptr. Maybe it would get more attention if I argued from personal conviction and dogma rather than trying to write correctly synchronised code using the right barriers ;-)