Re: [Boost-build] no-op thread variants on linux?

From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-01-24 06: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