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-15 17:18:43

Roland Schwarz writes:

    mat> 3) suggested that what I want to do, and was able to do in
    mat> 1.34.1, is cross-compilation and therefore an unreasonable
    mat> thing to ask for

    roland>  Really?
    roland>
    roland> This is what I said:
    roland>
    roland> I think what you are trying to do is some kind of cross
    roland> building with the mingw compiler for the cygwin
    roland> environment, yes?

I was referring to a different comment that you made. That is, when I said:

    mat> Mat Marcus wrote: My goal is to restore the state of affairs
    mat> to that of 1.34.1: the user didn't need to make any explicit
    mat> mention of the threadapi or target-os on the command line or
    mat> in the user-config.jam.

You replied:

    roland> I don't think this goal is reasonable.

    roland> You are doing essentially a cross compile, so you need to
    roland> specify the essential parts, which is <target-os> and
    roland> <threadapi>.

In any case, since Rene already answered my question, I will drop
this sub-thread.

    mat> 6) asked anthony not to fix what he might have regarded as a
    mat> bug in his thread jamfile without talking to you first

    roland> I asked this because 1) I wrote it.

Ok, that clarifies a few things. In that case, I will try to work with
a bit more you to help you understand an alternate point of view.

    mat> If so, great. My question is, what must I do to restore the
    mat> ability to use the following command line in 1.35.0:
    mat>
    mat> bjam debug release gcc-4.2.0 msvc-8.0 msvc-9.0

    roland> This indeed is possible, but 1) you need to decide which
    roland> threading api you want.

Why do I *need* to decide? I think that the ability to select either
threading model is a laudable improvement. On the other hand, I don't
see why we can't also pick some defaults that work when the user
doesn't explicitly want to select a threading model (as was the case
in 1.34.1).

    roland> 2) you need to separate the case whether you build from
    roland> bash or from cmd.

This is one of the points on which we differ most. Why should the
shell used determine the nature of the artifacts produced by a build
system? Why should the compiler used to create bjam affect the choices
of threading model in the built artifacts? I build cross-platform
libraries. I typically use some version of msvc on windows and some
version of gcc on the mac. I invoke

  bjam debug release gcc-4.2.0 msvc-8.0 msvc-9.0

from my bash shell in cygwin. Ensuring that the gcc-4.2.0 builds are
ok on windows reduces the number of surprises when I move the code to
the mac and compile with the darwin toolset. I have no desire to
change my workflow to write new scripts to use separate shells or
separately compiled versions of bjam in order to build with separate
compilers. Also, I also build using the cmd shell from time to time,
to make sure my users can do the same.

    roland> From your previous posts I deduce you have only msvc built
    roland> bjam. This implies one important consequence: It
    roland> determines the OS boost-build thinks it is on.
    roland> Even when you invoke from bash. You really be better off
    roland> to get your cygwin built bjam and get it picked up from
    roland> e.g.  /usr/local/bin.

I don't view cygwin as an OS. I view it as a shell, a compiler, and a
set of tools that is useful when running windows OS, under whichever
shell, and I claim that it is a bug for Jamfiles to depend on how bjam
was compiled. Not to mention the fact 1.35.0 seems to have broken
cygwin-gcc (not mingw) builds under my configuration and that, last I
checked, the msvc-built bjam was the only one that supported both msvc
and gcc toolsets.

    roland> I continue with building from cmd. Again from your
    roland> previous posts I have learned that the gcc you are using
    roland> is not a mingw. And there the next problem arises: gcc
    roland> wants to use cygwin dll by default.  You can switch this
    roland> off however: The switch (which is unfortuantely
    roland> undocumented, don't aks me why) is -mno-cygwin. This
    roland> should make your gcc try to link against mingw dll and
    roland> msvc rt dlls.

Why are you saying that it is a problem to use cygwin dll? I
understand that some users may not wish to use it, but this is not a
problem for me. I don't wish to link against mingw dll or msvc rt dlls
at present. Can we eliminate mingw from the discussion now?

    roland>  To sum up: While your setup should work in principle it
    roland> is not very solid when you are not exactly trying to find
    roland> out what is going on under the hoods.

I view it as: my setup was working fine in 1.34.1. But then you made
some changes to the boost thread jamfile that made threads depend on
how the bjam tool was compiled, introducing what I would claim
is a 1.35.0 bug.

    roland> I recommend
    roland>
    roland> 1) Using the mingw compilers and mingw (or msvc) built
    roland> bjam when compiling from cmd.

This is a fine use case. But it is not the only one, and it is not mine.
I don't wish to see the other use cases broken in order to support it.

    roland> 2) Using cygwin gcc and bjam built from bash with cygwing
    roland> gcc.

I argue that, while it may make implementor's lives easier, it does
not benefit users to have to compile different versions of bjam in
order to use different toolsets.

 - Mat