"liug" <g....@dialogic.com> writes: > What is the differenct between -pthread and -lpthread (with additional l)? > thanks
Without any context I'll assume these are compiler options. For most C compilers on Unix systems, the -l option tells the compiler to link the program with the named library, so -lpthread means to link the pthread library, whose file name is usually libpthread.a, libpthread.so, or some variation thereof. You may have seen -lm with other programs, which means to link the m (math) library (libm.a, libm.so, etc.).
The -pthread option is probably an option that's required to build threaded programs with a specific compiler on a specific platform. For example, gcc on FreeBSD uses -pthread to link with an alternate version of libc. FreeBSD doesn't have a separate pthread library, so using -lpthread wouldn't work.
See the documentation for your compiler for more information.
"liug" <g....@dialogic.com> writes: > What is the differenct between -pthread and -lpthread (with additional l)? > thanks
Yeah, good luck with this question. I have been asking around about the g++ -pthread option for about half a year and nobody knows much. I have not met anybody who understands how the pthread.so library should be used either. No documentation, nothing. Everybody says "use -pthread, Luke!" but can not explain why.
On Thu, 10 May 2001 10:31:33 -0400, liug <g....@dialogic.com> wrote: >What is the differenct between -pthread and -lpthread (with additional l)? >thanks
difference: -pthread breaks down to: -D_REENTRANT -lpthread
so it saves you havng to define _REENTRANT when compiling your code.
Marcin Nowak wrote: > "liug" <g....@dialogic.com> writes:
> > What is the differenct between -pthread and -lpthread (with additional l)? > > thanks
> Yeah, good luck with this question. I have been asking around about > the g++ -pthread option for about half a year and nobody knows much. > I have not met anybody who understands how the pthread.so library > should be used either. No documentation, nothing. > Everybody says "use -pthread, Luke!" but can not explain why.
This is like saying "why put -lm in my Makefile when I could use /usr/lib/libm.a?" The answer is that the latter is less general and more limiting. You're presuming a file path (which won't work on most other systems), you've built a (probably unintentional) dependency on a static archive version when you ought to be using a shared library. If you'd used -lm from way back in the dark ages of UNIX, as you should, your code would have automatically switched over to libm.so or libm.shlib or whatever name is appropriate on each system that introduced shared libraries.
It's the same with -pthread. If you know precisely what the compiler and linker do when presented with -pthread on the particular version of the specific system you're now using, you'll get identical results by using the various switches directly. For many systems, -pthread is just "-D_REENTRANT -lpthread". But what if your system doesn't have a libpthread? What if it needs -D_MT instead of -D_REENTRANT? What if a new version introduces better integration with C++ exceptions by adding a thread library dependency on a "libexception" library? If you use -pthread, none of this will affect you. You'll always build as the designers intend on each version of each system.
Then again, UNIX 98 refused to accept -pthread as the standard switch. So the only true formal STANDARD for building a threaded application is, unfortunately, "c89 -lpthread". By loose implication, the c89 compiler driver must add whatever semantics are necessary to this special -l switch value, including -D_REENTRANT. However, most systems still aren't UNIX 98 conforming, and, in any case, I doubt many real applications are actually built using the c89 command. Short of this, the -pthread switch is the most widely available defacto standard. (And that's not saying much, really, but it's all we've got.)
Dave Butenhof <David.Buten...@compaq.com> wrote: : Marcin Nowak wrote: :> "liug" <g....@dialogic.com> writes:
<snip> : Then again, UNIX 98 refused to accept -pthread as the standard switch. So the : only true formal STANDARD for building a threaded application is, : unfortunately, "c89 -lpthread". By loose implication, the c89 compiler driver : must add whatever semantics are necessary to this special -l switch value, : including -D_REENTRANT. However, most systems still aren't UNIX 98 conforming, : and, in any case, I doubt many real applications are actually built using the : c89 command. Short of this, the -pthread switch is the most widely available : defacto standard. (And that's not saying much, really, but it's all we've got.)
OK, and even though I'm not the OP, I'd still like to pose the question:
How does one FIND OUT about the -pthread option other than by "oral tradition" in places such as this newsgroup? I don't recall having read about it anywhere before seeing it referred to here, and I've been studying the subject for nearly a year, including reading Mr. Butenhof's (excellent, BTW) book, all the FAQs I could find, etc. Where is it documented?
-- ---- Fred Smith -- fre...@fcshome.stoneham.ma.us ---------------------------- I can do all things through Christ who strengthens me. ------------------------------ Philippians 4:13 -------------------------------
fred smith wrote: > How does one FIND OUT about the -pthread option other than by "oral > tradition" in places such as this newsgroup? I don't recall having read > about it anywhere before seeing it referred to here, and I've been > studying the subject for nearly a year, including reading Mr. Butenhof's > (excellent, BTW) book, all the FAQs I could find, etc. Where is it > documented?
You should find (customarily minimal) documentation on the man page for your compiler. It ought to be mentioned in any reference manual on program development or the use of threads for your system.
It's not in my book for a couple of reasons. First, as I mentioned, it's not part of any real standard. Second, I was really trying to stay away from platform-specific information. While such information is clearly valuable to people on a specific platform, it's hard to keep up to date, and would have made the book much larger if I went into enough detail to be useful. That sort of information really belongs in a reference manual for the platform, where it can have a chance of being kept up to date. (Besides, at the time, there were very few implementations even remotely resembling POSIX threads, so there wasn't really a whole lot to say.)
In article <GDEKtu....@fcshome.stoneham.ma.us>, fred smith <fre...@fcshome.stoneham.ma.us> wrote:
% How does one FIND OUT about the -pthread option other than by "oral % tradition" in places such as this newsgroup? I don't recall having read % about it anywhere before seeing it referred to here, and I've been
-pthread is accepted by a few compilers: Compaq C on Tru64 Unix, gcc on freeBSD, linux, and possibly other platforms, and I think IBM C on Dynix.
It is listed as an option on the man pages for the compiler, on all those platforms except possibly Linux (or possibly some flavours of Linux). --
Patrick TJ McPhee Knightsbridge SW7 p...@interlog.com
fred smith <fre...@fcshome.stoneham.ma.us> writes: > How does one FIND OUT about the -pthread option other than by "oral > tradition" in places such as this newsgroup? I don't recall having read > about it anywhere before seeing it referred to here, and I've been > studying the subject for nearly a year, including reading Mr. Butenhof's > (excellent, BTW) book, all the FAQs I could find, etc. Where is it > documented?
Dave Butenhof <David.Buten...@compaq.com> writes: > fred smith wrote:
> > How does one FIND OUT about the -pthread option other than by "oral > > tradition" in places such as this newsgroup? I don't recall having read > > about it anywhere before seeing it referred to here, and I've been > > studying the subject for nearly a year, including reading Mr. Butenhof's > > (excellent, BTW) book, all the FAQs I could find, etc. Where is it > > documented?
> You should find (customarily minimal) documentation on the man page for your > compiler. It ought to be mentioned in any reference manual on program development or > the use of threads for your system.
Hi, The g++2.95.2 on Linux has 0 (that is ZERO) references to -pthread option in any possible documentation I could think of. That is a problem, because I am trying to convince a company that supplies our shared libraries to use this option and have nothing "written" to back me. And judging from the g++ spec file, -pthread combined with -shared is just IGNORED during linking. So, in this case using -lpthread and -pthread is VERY different. I would like very much to hear some comments about that fact. Is linking with -lpthread a bad thing when creating shared libraries?
Marcin Nowak wrote: > The g++2.95.2 on Linux has 0 (that is ZERO) references to -pthread > option in any possible documentation I could think of. That is a > problem, because I am trying to convince a company that supplies our > shared libraries to use this option and have nothing "written" to back > me.
What you should tell them is that their code won't WORK if it's not compiled and linked CORRECTLY. The only additional argument for -pthread is that, if available, it is the easiest, most reliable, and most portable way to ensure that threaded code is built correctly. If they want to build correctly without using -pthread, that's fine... as long as it really IS correct! It's just more work for them, that way. (And every time they rebuild on a new version, they need to be sure that the way they did it manually is STILL correct.)
> And judging from the g++ spec file, -pthread combined with -shared is > just IGNORED during linking. So, in this case using -lpthread and > -pthread is VERY different. I would like very much to hear some > comments about that fact. Is linking with -lpthread a bad thing when > creating shared libraries?
If g++ ignores -pthread when you use -shared, that sounds like a bug. If code is intended to run with threads (even if it doesn't CREATE threads), it needs to be compiled (on most systems) with some specific switches (often -D_REENTRANT). There's no excuse for ignoring -pthread in this case.
You definitely should use -pthread to build shared libraries. If you don't (or can't) then you absolutely must compile with the proper switches. Often, you could get away without -lpthread on the link as long as your shared library doesn't reference pthread symbols; OR if you use a linker option to ignore unresolved symbols until load time.
On some systems, simply linking a shared library -pthread (or equivalent) may be enough to get proper threaded behavior. On some, though, in the absence of the thread library another runtime (usually the C runtime) provides pthread_* symbols that operate in a degraded mode, usually ignoring synchronization operations and failing on thread creation and such. The presence of a thread library means the process has TWO definitions for each, and normal UNIX symbol preemption rules apply. That means, if anything in the process is to use threads, you need to be sure that those symbols are resolved from the thread library. That usually means you need to be sure that the MAIN program is built with -lpthread, even if it doesn't use threads. (For example, on such a system you cannot write a threaded plugin for a non-threaded Netscape browser, unless the non-threaded browser was "spuriously" linked with the thread library!)
If the main program links against threads, and your threaded shared library is properly COMPILED and you use linker options to link despite unresolved symbols... then you're just fine even though you didn't link against the thread library. (Or, if all of the pthread symbols are in the C runtime, there wouldn't be any unresolved symbols anyway.) If the main program isn't linked against the thread library, and you're on a system where the C runtime will preempt all the pthread symbols, then linking your shared library against threads is hopeless anyway; though on some other systems it'll work just fine.
You don't need to worry about a lot of this if just you always build correctly. Again, -pthread is just a convenience to make it easier to build correctly. But it's a big convenience where it's available, and there's no reason NOT to use it.
Dave Butenhof <David.Buten...@compaq.com> writes: > Marcin Nowak wrote:
> > The g++2.95.2 on Linux has 0 (that is ZERO) references to -pthread > > option in any possible documentation I could think of. That is a > > problem, because I am trying to convince a company that supplies our > > shared libraries to use this option and have nothing "written" to back > > me.
> What you should tell them is that their code won't WORK if it's not > compiled and linked CORRECTLY. The only additional argument for > -pthread is that, if available, it is the easiest, most reliable, > and most portable way to ensure that threaded code is built > correctly. If they want to build correctly without using -pthread, > that's fine... as long as it really IS correct! It's just more work > for them, that way. (And every time they rebuild on a new version, > they need to be sure that the way they did it manually is STILL > correct.)
Dave, *I* believe you, but there is no proof I can present them and say: look, here it says you should use -pthread option. They will likely answer that they can not use some undocumented option in the software they sell, only because I say so. I will try to convince them anyhow, but I don't have much hope in succeeding.
> > And judging from the g++ spec file, -pthread combined with -shared is > > just IGNORED during linking. So, in this case using -lpthread and > > -pthread is VERY different. I would like very much to hear some > > comments about that fact. Is linking with -lpthread a bad thing when > > creating shared libraries?
> If g++ ignores -pthread when you use -shared, that sounds like a > bug. If code is intended to run with threads (even if it doesn't > CREATE threads), it needs to be compiled (on most systems) with some > specific switches (often -D_REENTRANT). There's no excuse for > ignoring -pthread in this case.
What can I say? Please compare the two sets of libraries used by g++ on Linux for linking. I don't think this is a bug. I just would like to understand why -lpthread disappears with -shared and I would like to hear somebody say that it IS, or IS NOT a bad thing to use -lpthread when linking shared libraries.
You say that we should use -lpthread, but that is not what g++ driver is doing. We actually think that linking with libpthread is making our programs crash.
> > The g++2.95.2 on Linux has 0 (that is ZERO) references to -pthread > > option in any possible documentation I could think of. That is a > > problem, because I am trying to convince a company that supplies our > > shared libraries to use this option and have nothing "written" to back > > me.
> What you should tell them is that their code won't WORK if it's not compiled and linked > CORRECTLY. The only additional argument for -pthread is that, if available, it is the > easiest, most reliable, and most portable way to ensure that threaded code is built > correctly. If they want to build correctly without using -pthread, that's fine... as long > as it really IS correct! It's just more work for them, that way. (And every time they > rebuild on a new version, they need to be sure that the way they did it manually is STILL > correct.)
> > And judging from the g++ spec file, -pthread combined with -shared is > > just IGNORED during linking. So, in this case using -lpthread and > > -pthread is VERY different. I would like very much to hear some > > comments about that fact. Is linking with -lpthread a bad thing when > > creating shared libraries?
> If g++ ignores -pthread when you use -shared, that sounds like a bug. If code is intended > to run with threads (even if it doesn't CREATE threads), it needs to be compiled (on most > systems) with some specific switches (often -D_REENTRANT). There's no excuse for ignoring > -pthread in this case.
Dave, the OP didn't read the entire `specs' file. The `-pthread' option _is_ ignored when linking shared objects, but _does_ set the `-REENTRANT' flag for the preprocessor step (where it matters).
> You definitely should use -pthread to build shared libraries. If you don't (or can't) > then you absolutely must compile with the proper switches. Often, you could get away > without -lpthread on the link as long as your shared library doesn't reference pthread > symbols; OR if you use a linker option to ignore unresolved symbols until load time.
Actually, as it turns out, the reason that the `-pthread' option is ignored in linking shared objects (on Linux) is that the linuxthreads library, because of the fact that it uses function interposition (specifically, but not limited to geting the IO right) is extremely sensitive to link order. The other problem is that explicit linking would tie you more tightly than necessary to a particular version of the threads library.
> On some systems, simply linking a shared library -pthread (or equivalent) may be enough > to get proper threaded behavior. On some, though, in the absence of the thread library > another runtime (usually the C runtime) provides pthread_* symbols that operate in a > degraded mode, usually ignoring synchronization operations and failing on thread creation > and such. The presence of a thread library means the process has TWO definitions for > each, and normal UNIX symbol preemption rules apply. That means, if anything in the > process is to use threads, you need to be sure that those symbols are resolved from the > thread library. That usually means you need to be sure that the MAIN program is built > with -lpthread, even if it doesn't use threads. (For example, on such a system you cannot > write a threaded plugin for a non-threaded Netscape browser, unless the non-threaded > browser was "spuriously" linked with the thread library!)
Yes. The only reason to link with the thread library explicitly (i.e. using `-lpthread' explicitly) is to deal with cases like this, where you're using thread functionality in a situation where the program itself doesn't.
> If the main program links against threads, and your threaded shared library is properly > COMPILED and you use linker options to link despite unresolved symbols... then you're > just fine even though you didn't link against the thread library. (Or, if all of the > pthread symbols are in the C runtime, there wouldn't be any unresolved symbols anyway.) > If the main program isn't linked against the thread library, and you're on a system where > the C runtime will preempt all the pthread symbols, then linking your shared library > against threads is hopeless anyway; though on some other systems it'll work just fine.
> You don't need to worry about a lot of this if just you always build correctly. Again, > -pthread is just a convenience to make it easier to build correctly. But it's a big > convenience where it's available, and there's no reason NOT to use it.
It's a convenience, yes, but when provided. _definitely_ use it -- it'll certainly save you from possible future headaches.
Cheers, --ag
-- Artie Gold, Austin, TX (finger the cs.utexas.edu account for more info) mailto:ag...@bga.com or mailto:ag...@cs.utexas.edu -- I am looking for work. Contact me.
> Actually, as it turns out, the reason that the `-pthread' option is > ignored in linking shared objects (on Linux) is that the linuxthreads > library, because of the fact that it uses function interposition > (specifically, but not limited to geting the IO right) is extremely > sensitive to link order. The other problem is that explicit linking > would tie you more tightly than necessary to a particular version of the > threads library.
Thanks for this bit of information. I will try to use it as an argument for not linking with -lpthread.
I actually think that explicit linking does not only tie one to a particular version of the library, but to a version of the symbol! There are different "versions" of the same symbols in the standard pthread.so library (talking RedHat6.1 here):
lib % nm libpthread-0.8.so |grep pthread_create 0000730c t __pthread_create_2_0 00007df4 t __pthread_create_2_1 00007df4 T pthread_create@@GLIBC_2.1 0000730c T pthread_create@GLIBC_2.0
Anybody can explain this versioning mechanism?
And one more thing that might be a problem: our stdc++.so library in g++ 2.95.2 seems to be linked with pthread.so, because it got this GLIBC "marks" in 2 symbols. I have checked, libraries linked without -lpthread do not get this "marks". So, is that bad? Because it is exactly in pthread_mutex_lock() where our applications crash.
nm -C libstdc++-3-libc6.1-2-2.10.0.so |grep pthread U __pthread_atfork U __pthread_getspecific U __pthread_initialize U __pthread_key_create U __pthread_mutex_destroy U __pthread_mutex_init U __pthread_mutex_lock U __pthread_mutex_trylock U __pthread_mutex_unlock U __pthread_mutexattr_destroy U __pthread_mutexattr_init U __pthread_mutexattr_settype U __pthread_once U __pthread_setspecific U _pthread_cleanup_pop_restore U _pthread_cleanup_push_defer U pthread_mutex_lock@@GLIBC_2.0 U pthread_mutex_unlock@@GLIBC_2.0
> "Arthur H. Gold" <ag...@bga.com> writes: > > Actually, as it turns out, the reason that the `-pthread' option is > > ignored in linking shared objects (on Linux) is that the linuxthreads > > library, because of the fact that it uses function interposition > > (specifically, but not limited to geting the IO right) is extremely > > sensitive to link order. The other problem is that explicit linking > > would tie you more tightly than necessary to a particular version of the > > threads library.
> Thanks for this bit of information. I will try to use it as an > argument for not linking with -lpthread.
> I actually think that explicit linking does not only tie one to a > particular version of the library, but to a version of the symbol! > There are different "versions" of the same symbols in the standard > pthread.so library (talking RedHat6.1 here):
> lib % nm libpthread-0.8.so |grep pthread_create > 0000730c t __pthread_create_2_0 > 00007df4 t __pthread_create_2_1 > 00007df4 T pthread_create@@GLIBC_2.1 > 0000730c T pthread_create@GLIBC_2.0
> Anybody can explain this versioning mechanism?
> And one more thing that might be a problem: our stdc++.so library in > g++ 2.95.2 seems to be linked with pthread.so, because it got this > GLIBC "marks" in 2 symbols. I have checked, libraries linked without > -lpthread do not get this "marks". So, is that bad? > Because it is exactly in pthread_mutex_lock() where our applications > crash.
> nm -C libstdc++-3-libc6.1-2-2.10.0.so |grep pthread > U __pthread_atfork > U __pthread_getspecific > U __pthread_initialize > U __pthread_key_create > U __pthread_mutex_destroy > U __pthread_mutex_init > U __pthread_mutex_lock > U __pthread_mutex_trylock > U __pthread_mutex_unlock > U __pthread_mutexattr_destroy > U __pthread_mutexattr_init > U __pthread_mutexattr_settype > U __pthread_once > U __pthread_setspecific > U _pthread_cleanup_pop_restore > U _pthread_cleanup_push_defer > U pthread_mutex_lock@@GLIBC_2.0 > U pthread_mutex_unlock@@GLIBC_2.0
> Marcin
The symbols in question are actually from libc. The results of an `ldd' on the aforementioned library are:
so there is no explicit link to libpthread.so (In fact, you'll see these symbols if you do the equivalent `nm' on libc -- they are `stubs' provided largely so you can make shared libraries thread-aware, without having the thread library, and its associated initialization code, in the link.
One thing you might want to look at is the `specs' file for your gcc installation (you'll notice that when shared libraries are linked using `-pthread' the flag is ignored -- which is what you want; otherwise link order gets messed up).
Information about versioning should be available in the info pages for `ld', where it talks about version scripts. Basically it's a way of having multiple versions of the same function within the library so code originally linked against an older version will still work.
HTH, --ag
-- Artie Gold, Austin, TX (finger the cs.utexas.edu account for more info) mailto:ag...@bga.com or mailto:ag...@cs.utexas.edu -- I am looking for work. Contact me.
