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

From: Mat Marcus (mat-lists_at_[hidden])
Date: 2008-04-17 15:40:38

On Thu, Apr 17, 2008 at 11:02 AM, Roland Schwarz
<roland.schwarz_at_[hidden]> wrote:
> Finally I was able to reproduce Mat's findings and also
> found the solution to this problem.

Thanks for your continued interest in this matter.

> It was just by chance that compiling the thread lib triggered
> the problem. Other libs might also be affected, but this depends
> on whether they care if it is important to link against
> cygwindll or msvc rt.
>
> Since gcc.jam has no means to choose which dll to link against
> (not sure if this should or could be handled by <std-lib> feature),
> user intervention is necessary.
>
> This can be done by specifying
> <cxxflags>-mno-cygwin
> <linkflags>-mno-cygwin
> in user-config.jam

Why must users specify -mno-cygwin to use the thread library?

>
> or
>
> by having the init rule of gcc add these flags when the host os
> is windows _and_ gcc is not mingw but cygwin-gcc that tries to
> compile mingw executables.

You keep mentioning mingw. What about users who are not trying to
compile mingw exectuables, and who haven't installed any mingw
compilers or headers on their machine?

> Mat, so I recommend to put the both options into your user-config.jam.

Why is the better than Rene's suggestion to put:

toolset.add-requirements
  <toolset>gcc-4.2.0:<target-os>cygwin
  <toolset>gcc-4.2.0:<threadapi>pthread ;

into user-config.jam?

> I still do not recommend to use msvc compiled bjam from bash.

Bash is my shell. It is essential to my workflows. In fact, I find
windows unusable without it :-). Msvc is one of the compilers that I
must support. I must also ensure that users of my libraries can build
from the CMD shell.

I argue that it is a bug if a build system cannot produce the same
artifacts for a user's chosen toolset under the user's chosen shell,
or if the artifacts on a single machine depend on how the built tool
itself was compiled.

> This is mainly because the default setting of the target-os is not
> correct, but also because bjam will not try to locate user-config.jam
> from your cygwin home directory.

Sure it will. Simply set %HOME% to the cygwin home dir. See page
37 of the boost build userman.pdf. I use C:\home.

> While it _might_ be possible to share the home directory between
> windows and cygwin, you are likely to ask for trouble.  If you have
> found a robust way of doing so, please let me know! I did not succed
> since I am using cygwin.
>  Roland --

>From what I understand, it is not uncommon to setup %HOME% to
accomplish this.

In general, I would ask that, all others things being equal, Jamfile
authors try to preserve the user's ability to produce the same
artifacts for a given toolset, independent of their choice of shell.

I understand that this may be difficult at times.  Maybe we could
identify the circumstances under which Jamfile authors might need to
do something that breaks shell independence. Then we could perhaps
develop a feature request for boost build that would reconcile the
needs of the library jamfile authors and the users who would freely
mix toolsets under the shell of their choice.

For example, why is it necessary to view cygwin as an OS in the boost
thread jamfile? That is, why isn't it possible to determine default
choices for threadapi by dispatching on the toolset perhaps together
with something like the <toolset-gcc:flavor> property? I'd like to see
a system where Jamfile authors had sufficient resources from the build
system to avoiding depending on who compiled the built tool or even
which shell is in use. What, if anything, is currently missing?

 - Mat