Re: [Boost-build] [boost] [1.35.0] Threads - build failure using gcc on Win XP

From: Vladimir Prus (ghost_at_[hidden])
Date: 2008-04-22 03:08:41

On Monday 21 April 2008 15:40:25 Roland Schwarz wrote:
> 
> Vladimir Prus wrote:
> > Hmm, having glanced on this entire thread, I suspect we need to start from square one.
> > Roland, Anthony, can you describe what exact behaviour you want for building of
> > Boost.Threads?
> 
> Ok, I'll try to give a summary, and hopefully will be able to
> explain why some users might experience something like breakage,
> compared to the previous version 1.3.4.1.
> 
> In 1.3.4.1 there was one set of source files bb needed to
> consider. The choice of actual platform was delegated to the
> compiler. The target API was determined by compiler macros.
> 
> For two reasons we wanted to change that:
> 
> 1) Cleaner code, i.e. no complicated #fdef paths in the
>    source.
> 
> 2) Ability to create two libraries, one for native API and
>    one based on pthread API.
> 
> The include headers now are in api separated subdirectories,
> and on central config switches in the correct one at compile
> time. The mapping still is done by means of macros that
> determine the platform.
> 
> The situation is different for source, as now there are separate
> sources that need to be compiled. Of course it would have been
> possible to engage a similar mechansim as for headers, but I
> opted to hand this over to bb.
> 
> Consequently bb need to find the correct set of source files.
> 
> My intent was, that the user being able to request the threading
> API to use by specifying a feature, i.e. <threadapi>
> 
> This brings up the question of what is default, if nothing
> was explicitly requested. Also, to avoid the duplicate
> target error for installation it is necessary to change the
> tagging of the generated lib. Since I wanted to break as little
> as possible I tagged the "default" library as before, and added
> the "_pthread" tag to non-native builds.
> E.g. on windows both libraries are possible at the same time,
> i.e. libboost_thread and libboost_thread_pthread.
> 
> I based the notion of "default" upon what bjam gives for the
> OS. This works for most cases, but fails in the case Mat run
> against. Indeed it should be the compiler who decides what
> default is, else the header macros and compilation of sources
> will get out of sync.
> 
> The solution to this would be to condition threadapi on the
> compiler used. Unfortunately this is not possible to do in
> a robust way. All that a project can do, is to condition on
> a <toolset-gcc:version>. Since the version is under user
> control, i.e. what the user specified in unser-config.jam
> the choice of threadpi would depend on this.
> 
> Another option would be to condition on <toolset-gcc:flavor>.
> This solution would partly work, but has a serious short-coming.
> If multiple versions of the compiler are set up in user-config.jam
> and the user does not explicitely request the flavor on the
> command line, the default flavor will be choosen, i.e. the
> flavor of the first compiler. This is most likely not what
> the user expects (and also is wrong).

You can use cygwin gcc in both cygwin mode and -mno-cygwin mode. What
default threading api do you expect for the latter case, and can it be
inferred in any way from output of -dumpmachine?

- Volodya