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 18:42:18

On Tue, Apr 15, 2008 at 3:11 PM, Roland Schwarz
<roland.schwarz_at_[hidden]> wrote:
> Hi Mat,
>
> you are making alot of good points, one I favour most:
> *) don't break anything.
>
> However unfortunately the situation is far from ideal.
>
> Didn't someone in this thread say the compiler should determine the
> thread api? Do you know a reliable method? If so please
> tell me. (I am not talking about macros here, we do not have
> access to these.) Until then I use the approximation that
> bjam gives me and rely on users tweaking their setup for
> unusual setups. By unusual I mean: look at the boost regression
> pages and try to find out how common your setup is.

I'm not a boost build expert, so please allow the following naive
question: Is the problem that on windows the same toolset (gcc) might
want a different default threadapi according to whether or not it is a
mingw gcc? Or is the situation more complex?

> What complicates things is, I am not the maintainer of gcc.jam.
> gcc.jam already has a big load on it. It cannot omit any of the
> gcc variants and also needs to deal with a stranger, i.e. mingw
> compiler. Of course it is not a cross compiler, but perhaps it
> is a good aproach to view it in this light.
> It is hairy to change it without risk of break on some seemingly
> unrelated platform.
>
> I tried my best to to get at "make it just work". Ok I admit I
> failed for your case. Others so far can use the setup, and so can I.
>
> So what shall we do? Can you possibly supply not only a suggestion
> of how it should work, but also how to implement it?
>
> If so, please do.

Sorry if it seems otherwise, but I am in fact attempting to
contribute. My first order of business was to decribe the complex
issues involved, establish that there was a bug and to find a
workaround. Now that that's been square away, I am tyring to do what I
can to help find a solution.

> Do you mean I should drop support of pthread for mingw and msvc builds?

Of course not. Nor do I wish to claim that my particular use cases
must be supported with the minimum of user effort.

> If not please stick with Renes advice until a solution is found
> that will also work for your environment without heavy user-config.jam
> tweaking.

Yes, I will do so.

>
> I admit it would be nice if everything goes auto-config like.
> Still we are not there yet.

Sure. The urgency of my request faded when Rene answered my orginal
question. Now I am trying to be a good citizen by writing up the
appropriate bugs and drawing attention to use cases from the field
that were inadvertently broken. And to help if I can.

> Btw. this is what I am doing most of the time. My user config
> already contains lot of code to work around certain deficiencies,
> I was not able yet to convince the maintainers to implement.
>
> Also I did not complain, instead started to look into the problems
> and tried to help solve some of them.

I reported a bug, asked for help and thanked those who helped me. A
bug report is not a complaint. I did complain about your initial
responses to my attempt to get to the bottom of things, but I am
hoping that we are past that now.

> Btw. I just succeded building bjam both from 1.35.0 and trunk.
> Possibly you can check if your self compiled gcc does not work
> as you expect?
>
> Regards Roland

I tried this with both the cygwin-supplied gcc-3.4.4 and with a
chand-compiled gcc-4.2.0 with similar results. I pasted the results
for gcc-3.4.4 in another thread, and posed the question: what does
expand.c want l->string to be at the point where it asserts that it
must not be C:\foo\bar ?