|
List Info
Thread: no-op thread variants on linux?
|
|
| no-op thread variants on linux? |
|
2007-01-23 11:36:46 |
|
|
Hi!
By default, boost builds debug and thread variants. However, on linux at
least, only two of the actual boost libraries that are built for the
thread variant actually use threads: libboost_thread-mt and
libboost_regex-mt. (Via an admittedly rough inspection of library symbols.)
As libboost_thread doesn't come in a single thread variant, I'm
wondering if
libboost_date_time-mt.a
libboost_filesystem-mt.a
libboost_graph-mt.a
libboost_prg_exec_monitor-mt.a
libboost_program_options-mt.a
libboost_python-mt.a
libboost_serialization-mt.a
libboost_signals-mt.a
libboost_test_exec_monitor-mt.1
libboost_unit_test_framework-mt.a
libboost_wave-mt.a
libboost_wserialization-mt.a
And the corresponding shared objects are, in fact, no-ops on linux
targets? If not, can somebody give me some more insight onto what
practical difference the *-mt libraries above have from the
single-thread variant?
best,
-benjamin
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
|
| Re: no-op thread variants on linux? |
|
2007-01-23 14:19:01 |
On Tuesday 23 January 2007 20:36, Benjamin Kosnik wrote:
> As libboost_thread doesn't come in a single thread
variant, I'm
> wondering if
>
> libboost_date_time-mt.a
> libboost_filesystem-mt.a
> libboost_graph-mt.a
> libboost_prg_exec_monitor-mt.a
> libboost_program_options-mt.a
> libboost_python-mt.a
> libboost_serialization-mt.a
> libboost_signals-mt.a
> libboost_test_exec_monitor-mt.1
> libboost_unit_test_framework-mt.a
> libboost_wave-mt.a
> libboost_wserialization-mt.a
>
> And the corresponding shared objects are, in fact,
no-ops on linux
> targets? If not, can somebody give me some more insight
onto what
> practical difference the *-mt libraries above have from
the
> single-thread variant?
MT build with gcc on Linux has two properties:
1. It's linked against -lpthread
2. It's compiled with -D_REENTRANT
(1) matters only for shared libraries. I am not in position
to say
which of the above library have incompatible ABI changes due
to _REENTRANT.
I believe that program_options uses shared_ptr in interface,
so MT and ST variants
are not binary compatible. I believe some other libraries
might also differ between
MT and ST and it's easier to build two variants rather than
guess which libraries
need it and which don't.
HTH,
Volodya
>
> best,
> -benjamin
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
>
>
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
|
|
| Re: no-op thread variants on linux? |
|
2007-01-24 04:40:43 |
|
|
> MT build with gcc on Linux has two properties:
>
> 1. It's linked against -lpthread
> 2. It's compiled with -D_REENTRANT
Yeah. It's compiled with -pthread.
;)
> (1) matters only for shared libraries. I am not in position to say
> which of the above library have incompatible ABI changes due to _REENTRANT.
> I believe that program_options uses shared_ptr in interface, so MT and ST variants
> are not binary compatible. I believe some other libraries might also differ between
> MT and ST and it's easier to build two variants rather than guess which libraries
> need it and which don't.
I suppose if boost book was building, I could hack doxygen to do
collaboration graphs, and then we could know, and not guess... I guess
these dependencies aren't being accurately tracked?
It seems weird (and wasteful) to me that un-necessary libraries are
being built. Why aren't libs that have actual thread support opting in
to a -mt build?
Although all of these libs have -mt variants, only two (thread/regex)
have pthread symbols and four others
(serialization/wserialization/program_options/date_time) seem to use
bits from BOOST_HAS_THREADS. As you say, it's hard to tell what's
actually necessary.
best,
benjamin
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
|
| Re: no-op thread variants on linux? |
|
2007-01-24 05:26:53 |
|
| On Wednesday 24 January 2007 13:40, Benjamin Kosnik wrote:
>
> > MT build with gcc on Linux has two properties:
> >
> > 1. It's linked against -lpthread
> > 2. It's compiled with -D_REENTRANT
>
> Yeah. It's compiled with -pthread.
>
> ;)
>
> > (1) matters only for shared libraries. I am not in position to say
> > which of the above library have incompatible ABI changes due to _REENTRANT.
> > I believe that program_options uses shared_ptr in interface, so MT and ST variants
> > are not binary compatible. I believe some other libraries might also differ between
> > MT and ST and it's easier to build two variants rather than guess which libraries
> > need it and which don't.
>
> I suppose if boost book was building, I could hack doxygen to do
> collaboration graphs, and then we could know, and not guess... I guess
> these dependencies aren't being accurately tracked?
I don't follow, how? A single
#ifdef _REENTRANT
in sources or headers of any given library is enough to break ABI between MT and ST
version. I'm not aware of any automated way to check for that.
> It seems weird (and wasteful) to me that un-necessary libraries are
> being built. Why aren't libs that have actual thread support opting in
> to a -mt build?
The problem I see is outlined above -- you don't know which libs are different between MT
and ST builds.
> Although all of these libs have -mt variants, only two (thread/regex)
> have pthread symbols
And even we assume that external references to pthread symbols
is the same as "ABI differes between ST and MT", how do we know which
libs will depend on pthread symbols. Say, shared_ptr can be using pthread
or using lock-free algorithms, depending on compiler.
- Volodya
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
|
| Re: no-op thread variants on linux? |
|
2007-01-24 09:24:59 |
|
|
> I don't follow, how? A single
>
> #ifdef _REENTRANT
>
> in sources or headers of any given library is enough to break ABI between MT and ST
> version. I'm not aware of any automated way to check for that.
For your example of shared_ptr, you could use doxygen's collaboration
graphs to see which libs include shared_ptr includes. It's not
automated, but it's quite helpful.
I believe it also lets you track macros like BOOST_HAS_THREADS, which
seems to be how regex and others are marking up the sources for
thread-active code.
> The problem I see is outlined above -- you don't know which libs are different between MT
> and ST builds.
It is my contention that the boost build system should definitively know
this, at least for the boost libs.
-benjamin
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
|
[1-5]
|
|
|
about | contact Other archives ( Real Estate discussion Medical topics )
|