On Thu, 2007-01-11 at 18:06 -0800, Ian Lance Taylor wrote: > Paul Joselow <pjoselow@xxxxxxxxxxxxx> writes: > > > I work at a company that uses pthreads. I have some questions about what > > this option actually does during a compile. There are cases where even > > though a program uses pthreads, the option was omitted from the compile and > > build and the program builds successfully. So the questions involve what > > things will and will not work when the pthread option is used or omitted. > > This is a question I would like to answer across several architectures, > > specifically Alpha, Intel Linux, and Solaris. > > > > I have been shown a case where common variables (e.g. errno) that should be > > local to each thread end up being shared across all threads if the pthread > > option is omitted. What are the problems with always using the pthread > > option on all compiles and links regardless of whether a program uses > > pthreads or not? > > In typical cases, the gcc -pthread option does a #define of _REENTRANT > and causes gcc to link against -lpthread. That's it. With 'typical case' you mean Linux ? > > The library header files will typically act slightly different via > #ifdef _REENTRANT. Changing the declaration of errno is a typical > case. > > It's not surprising that some code works if you don't use -pthread. I'd like to say the other way round too, it's not surprising that applications just don't work if you mix with-pthread and without-pthread built libraries. For me, _always_ have pthreads enabled works much better than just leave the package's build mechanisms alone. In my case, this is true for x86-linux, hppa-hpux, ia64-hpux, sparc-solaris, x86-solaris and powerpc-aix. Thing is that some packages just ignore the CFLAGS/CXXFLAGS/LDFLAGS environment variables. The worst scenario when mixing pthread is on aix, where gcc chooses a different set of libraries to link: without -pthread: libgcc_s.a, libstdc++.a with -pthread: pthread/libstdc++.a libgcc_s_pthread.a To avoid this, and not to have the need to eventually fix the different build mechanisms of many different packages, I use a self-built gcc with a patch to always have pthreads enabled on all my platforms even without having -pthread on commandline. Just to be noted: Building a package with pthreads enabled on the compiler level does not mean that this package itself is thread-save, nor does it mean that threads are used by the application. It just means that the thread-save implementations of libc and stl are used (correct me if this is wrong). If there is interest, I can post this patch (for gcc-4.1.1), which is tested on the above mentioned platforms, although I did the patch for almost all platforms supporting the -pthread flag I found in the gcc-sources. /haubi/
