What is the differenct between -pthread and -lpthread (with additional l)?
来源：互联网 发布：sql修改表中的数据 编辑：程序博客网 时间：2024/04/30 16:55
thanks
> 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.
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
liug wrote:
> What is the differenct between -pthread and -lpthread (with additional l)?
> thanks
'-lpthread' means 'link with a library called pthread'.
'-pthread' means 'do whatever you have to do to compile code that
complies with the pthreads standard so that it works'.
'-lpthread' should not be used if '-pthread' is available unless you
have some very specific reason.
DS
> 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.
Marcin
>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.
thats the only diff I am aware of.
mal
>
> > What is the differenct between -pthread and -lpthread (with additional l)?
> > thanks
>
> 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.)
/------------------[ David.B...@compaq.com ]------------------\
| Compaq Computer Corporation POSIX Thread Architect |
| My book: http://www.awl.com/cseng/
\-----[ http://home.earthlink.net/~
: 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?
: /------------------[ David.B...@compaq.com ]------------------\
: | Compaq Computer Corporation POSIX Thread Architect |
: | My book: http://www.awl.com/cseng/
: \-----[ http://home.earthlink.net/~
--
---- Fred Smith -- fre...@fcshome.stoneham.ma.us ----------------------------
I can do all things through Christ
who strengthens me.
------------------------------ Philippians 4:13 ------------------------------
> 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.)
/------------------[ David.B...@compaq.com ]------------------\
| Compaq Computer Corporation POSIX Thread Architect |
| My book: http://www.awl.com/cseng/
\-----[ http://home.earthlink.net/~
fred smith <fre...@fcshome.stoneham.ma.
% 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
pt...@interlog.com
> (excellent, BTW) book, all the FAQs I could find, etc. Where is it
> documented?
You can find it in Bil's FAQ at:
http://www.lambdacs.com/cpt/
--
v
Ivica Loncar "I wish I was a neutron bomb for once I could go off"
> 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?
>
> 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
> 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.)
> 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.
/------------------[ David.B...@compaq.com ]------------------\
| Compaq Computer Corporation POSIX Thread Architect |
| My book: http://www.awl.com/cseng/
\-----[ http://home.earthlink.net/~
> 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.
% g++ --verbose -pthread -shared -o x.so x.o
Reading specs from /usr/local/gcc-alt-2.95.2/lib/
gcc version 2.95.2 19991024 (release)
/usr/local/gcc-alt-2.95.2/
% g++ --verbose -pthread -o x.exe x.o
Reading specs from /usr/local/gcc-alt-2.95.2/lib/
gcc version 2.95.2 19991024 (release)
/usr/local/gcc-alt-2.95.2/
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.
[snipped (but not ignored! the rest...]
>
> 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.)
>
> > 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.
_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.
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!)
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.
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.
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.
Marcin
on the aforementioned library are:
stellablue:/usr/lib$ ldd -r -d libstdc++-3-libc6.1-2-2.10.0.
libm.so.6 => /lib/libm.so.6 (0x4005c000)
libc.so.6 => /lib/libc.so.6 (0x4007a000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
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.
- What is the differenct between -pthread and -lpthread (with additional l)?
- What is the difference between -I and -L in makefile? and the means of -d.
- What is the difference between test, [ and [[ ?
- what is the difference between the setTimeout and setInterval
- What is the difference between DHTML and the DOM?
- What is the difference between the mouseover and mouseenter events?
- What is the difference between AWT and SWT?
- What is the difference between User Control and Custom Control?
- What is the difference between an EXE and a DLL?
- What is the difference between XML and C or C ?
- What is the difference between SMOD and CMOD?
- what is the difference between little-endian and big-endian.
- What is the difference between procedural and nonprocedural language?
- What is the difference between a thread and a process?
- What is the difference between objectForKey and valueForKey?
- What is the difference between Microsoft TMG and UAG ?
- What is the Difference Between http and https?
- what is the difference between ELF files and bin files
- @include与jsp:include的区别
- MYSQL 获取指定时间之间天数
- 图片链接与字形
- TCP/IP通信架构
- 【【【超高仿】】】迅雷播放器教程 -- 总结(14)
- What is the differenct between -pthread and -lpthread (with additional l)?
- delphi xe2 下TListView的ViewStyle设置vsList后列宽显示问题
- Linux Shell中的特殊字符
- 设计模式学习之单例模式
- LE一个通过java串口通信控制LED显示数据的实例
- Ext.net Chart 使用心得(一)
- 写给浮躁的IT同仁(请不要做浮躁的人)
- puppet中exec使用
- SQL SERVER 合并重复行，行列转换
