[boost] [build] bootstrap.sh is still broken

[Stephan T. Lavavej]

Hi,

For months, I've been pinging the boost-build list about bootstrap.sh being
completely broken for MinGW, with no response.

As the 1.55.0 branch is closing in just a week, it would be wonderful if
somebody could look at and apply my two patches that are ready to go:
http://lists.boost.org/boost-build/2013/10/27025.php

Note that they will fix this: https://svn.boost.org/trac/boost/ticket/8762

Thanks,
STL


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Dave Abrahams]

on Sat Oct 19 2013, "Stephan T. Lavavej" <stl-AT-nuwen.net> wrote:

> Hi,
>
> For months, I've been pinging the boost-build list about bootstrap.sh being
> completely broken for MinGW, with no response.
>
> As the 1.55.0 branch is closing in just a week, it would be wonderful if
> somebody could look at and apply my two patches that are ready to go:
> http://lists.boost.org/boost-build/2013/10/27025.php
>
> Note that they will fix this: https://svn.boost.org/trac/boost/ticket/8762

If the maintainers are unresponsive to something like this it would seem
to argue for giving up on Boost.Build ASAP.

--
Dave Abrahams

[Edward Diener]

On 10/20/2013 11:58 PM, Dave Abrahams wrote:
>
> on Sat Oct 19 2013, "Stephan T. Lavavej" <stl-AT-nuwen.net> wrote:
>
>> Hi,
>>
>> For months, I've been pinging the boost-build list about bootstrap.sh being
>> completely broken for MinGW, with no response.
>>
>> As the 1.55.0 branch is closing in just a week, it would be wonderful if
>> somebody could look at and apply my two patches that are ready to go:
>> http://lists.boost.org/boost-build/2013/10/27025.php
>>
>> Note that they will fix this: https://svn.boost.org/trac/boost/ticket/8762
>
> If the maintainers are unresponsive to something like this it would seem
> to argue for giving up on Boost.Build ASAP.

Isn't there actually just a single offical maintainer of Boost Build,
which may be the problem ? If that maintainer does not have the time or
the will to make changes or to add code, then quite probably nothing
will get done. Unless of course others, who are knowledgeable about the
bjam language and the Boost Build "libraries", are also available to
maintain and add to the Boost Build code. Other than Steve Watanabe, who
may also be busy or unavailable, I do not know of any others who have
actively helped maintain Boost Build.

[Rene Rivera]

Sorry if I hadn't gotten any time to look at MinGW building.. But I have
had higher priority tasks (like getting a library into Boost, presenting a
paper to LEWG, full time work, family, photo exhibition, etc.) to look into
a patch I can't directly test, or apply.

Sorry that sounded harsh.. But so does your response Dave.

--
--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

[Rene Rivera]

Stephan,

Could you post the diff patches as attachments? It's almost impossible to
deal with inline diffs to apply these. Even though I can't test any of
this. I'm willing to apply the patches.

--
--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

[Vladimir Prus]

On 21.10.2013 07:58, Dave Abrahams wrote:
>
> on Sat Oct 19 2013, "Stephan T. Lavavej" <stl-AT-nuwen.net> wrote:
>
>> Hi,
>>
>> For months, I've been pinging the boost-build list about bootstrap.sh being
>> completely broken for MinGW, with no response.
>>
>> As the 1.55.0 branch is closing in just a week, it would be wonderful if
>> somebody could look at and apply my two patches that are ready to go:
>> http://lists.boost.org/boost-build/2013/10/27025.php
>>
>> Note that they will fix this: https://svn.boost.org/trac/boost/ticket/8762
>
> If the maintainers are unresponsive to something like this it would seem
> to argue for giving up on Boost.Build ASAP.

We might want to first give up on git transition, given that after all these
years you are still *discussing* what is the appropriate workflow?

And on the mingw topic, I might have missed something, but I think the major
issue is still mingw vs. gcc naming inconsistency between bootstrap.sh
and b2 proper - which is ugly, but not quite a showstopper?

- Volodya

[Stephan T. Lavavej]

[STL]
> http://lists.boost.org/boost-build/2013/10/27025.php

[Rene Rivera]

> Could you post the diff patches as attachments? It's almost impossible to
> deal with inline diffs to apply these. Even though I can't test any of
> this. I'm willing to apply the patches.

Thanks! Download this: http://nuwen.net/stuff/boost-bootstrap.patch

As I explained in my mail, the diff for boost_1_54_0/bootstrap.sh is a
horrible hack and should not be applied. It fixes mingw but breaks everyone
else. I would love to get a real fix for this, but someone would have to
investigate.

The diffs for boost_1_54_0/tools/build/v2/engine/build.jam and
boost_1_54_0/tools/build/v2/engine/build.sh should be applied - they fix
mingw and should not affect anyone else.

[Vladimir Prus]

> And on the mingw topic, I might have missed something, but I think the
major
> issue is still mingw vs. gcc naming inconsistency between bootstrap.sh
> and b2 proper - which is ugly, but not quite a showstopper?

That's what my boost_1_54_0/bootstrap.sh diff is hacking around. It's a
showstopper in the sense that it completely breaks the build, and I haven't
figured out how to evade it with command-line arguments.

[Vladimir Prus]

On 21.10.2013 21:03, Stephan T. Lavavej wrote:
> [STL]
>> http://lists.boost.org/boost-build/2013/10/27025.php
>
> [Rene Rivera]
>> Could you post the diff patches as attachments? It's almost impossible to
>> deal with inline diffs to apply these. Even though I can't test any of
>> this. I'm willing to apply the patches.
>
> Thanks! Download this: http://nuwen.net/stuff/boost-bootstrap.patch
>
> As I explained in my mail, the diff for boost_1_54_0/bootstrap.sh is a
> horrible hack and should not be applied. It fixes mingw but breaks everyone
> else. I would love to get a real fix for this, but someone would have to
> investigate.
>
> The diffs for boost_1_54_0/tools/build/v2/engine/build.jam and
> boost_1_54_0/tools/build/v2/engine/build.sh should be applied - they fix
> mingw and should not affect anyone else.
>
> [Vladimir Prus]
>> And on the mingw topic, I might have missed something, but I think the
> major
>> issue is still mingw vs. gcc naming inconsistency between bootstrap.sh
>> and b2 proper - which is ugly, but not quite a showstopper?
>
> That's what my boost_1_54_0/bootstrap.sh diff is hacking around. It's a
> showstopper in the sense that it completely breaks the build, and I haven't
> figured out how to evade it with command-line arguments.

Ok. Rene, Steven, how about we s/mingw/gcc throughout b2 engine source?

- Volodya

[Rene Rivera]

On Mon, Oct 21, 2013 at 12:32 PM, Vladimir Prus <gh...@cs.msu.su> wrote:

> On 21.10.2013 21:03, Stephan T. Lavavej wrote:
>
>> [STL]
>>

>>> http://lists.boost.org/boost-**build/2013/10/27025.php<http://lists.boost.org/boost-build/2013/10/27025.php>

>>>
>>
>> [Rene Rivera]
>>
>>> Could you post the diff patches as attachments? It's almost impossible to
>>> deal with inline diffs to apply these. Even though I can't test any of
>>> this. I'm willing to apply the patches.
>>>
>>

>> Thanks! Download this: http://nuwen.net/stuff/boost-**bootstrap.patch<http://nuwen.net/stuff/boost-bootstrap.patch>

>>
>> As I explained in my mail, the diff for boost_1_54_0/bootstrap.sh is a
>> horrible hack and should not be applied. It fixes mingw but breaks
>> everyone
>> else. I would love to get a real fix for this, but someone would have to
>> investigate.
>>

>> The diffs for boost_1_54_0/tools/build/v2/**engine/build.jam and
>> boost_1_54_0/tools/build/v2/**engine/build.sh should be applied - they

>> fix
>> mingw and should not affect anyone else.
>>
>> [Vladimir Prus]
>>
>>> And on the mingw topic, I might have missed something, but I think the
>>>
>> major
>>
>>> issue is still mingw vs. gcc naming inconsistency between bootstrap.sh
>>> and b2 proper - which is ugly, but not quite a showstopper?
>>>
>>
>> That's what my boost_1_54_0/bootstrap.sh diff is hacking around. It's a
>> showstopper in the sense that it completely breaks the build, and I
>> haven't
>> figured out how to evade it with command-line arguments.
>>
>
> Ok. Rene, Steven, how about we s/mingw/gcc throughout b2 engine source?
>

Fine by me.. But since I no longer have, or can get setup, a MinGW install
it's not something I will be able to test at all :-(

--
--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

[Vladimir Prus]

Well, I do have a Windows box, but last time I checked, there was a dozen of flavours
of MinGW. Stephan, can you point at whatever packages needs to be downloaded to
try?

- Volodya

[Steven Watanabe]

AMDG

I agree in principle, but it's not quite that easy.
mingw is treated slightly differently from gcc
(windows sources, not unix).

In Christ,
Steven Watanabe

[Niall Douglas]

On 21 Oct 2013 at 21:46, Vladimir Prus wrote:

> Well, I do have a Windows box, but last time I checked, there was a dozen of flavours
> of MinGW. Stephan, can you point at whatever packages needs to be downloaded to
> try?

Be aware that I found any Mingw after the one based on GCC 4.6.4 is
broken with Boost in various unhelpful ways (e.g. generating
assembler ops its assembler won't accept). In fact, of course, Mingw
with GCC 4.6 was also broken (e.g. <atomic> does not implement
actually atomic operations), but it had been around long enough
people had patched for it.

Mingw-w64 is absolutely fine though, and I very strongly recommend
its use over traditional Mingw. Mingw-w64 was so trouble free that it
just worked for me first time, which was quite a novel experience.

Niall

--
Currently unemployed and looking for work.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

[niXman]

Niall Douglas писал 2013-10-22 03:47:

> On 21 Oct 2013 at 21:46, Vladimir Prus wrote:
>
>> Well, I do have a Windows box, but last time I checked, there was a
>> dozen of flavours
>> of MinGW. Stephan, can you point at whatever packages needs to be
>> downloaded to
>> try?
>
> Be aware that I found any Mingw after the one based on GCC 4.6.4 is
> broken with Boost in various unhelpful ways (e.g. generating
> assembler ops its assembler won't accept). In fact, of course, Mingw
> with GCC 4.6 was also broken (e.g. <atomic> does not implement
> actually atomic operations), but it had been around long enough
> people had patched for it.
>
> Mingw-w64 is absolutely fine though, and I very strongly recommend
> its use over traditional Mingw. Mingw-w64 was so trouble free that it
> just worked for me first time, which was quite a novel experience.
>
> Niall

MinGW-W64 based on the GCC-4.8.2(i686/x86_64, SEH/DWARF/SJLJ):
https://sourceforge.net/p/mingw-w64/mailman/message/31539678/

P.S.
I am sorry for offtopic, but can anybody tell me please, will
boost.coroutine support MinGW in boost-1.55? On the bugtracker I saw the
patch, will it be applied?
Thanks.

--
Regards, niXman
___________________________________________________
Dual-target(32 & 64-bit) MinGW compilers for 32 and 64-bit Windows:
http://sourceforge.net/projects/mingw-w64/
___________________________________________________
Another online IDE: http://liveworkspace.org/

[Edward Diener]

On 10/21/2013 7:47 PM, Niall Douglas wrote:
> On 21 Oct 2013 at 21:46, Vladimir Prus wrote:
>
>> Well, I do have a Windows box, but last time I checked, there was a dozen of flavours
>> of MinGW. Stephan, can you point at whatever packages needs to be downloaded to
>> try?
>
> Be aware that I found any Mingw after the one based on GCC 4.6.4 is
> broken with Boost in various unhelpful ways (e.g. generating
> assembler ops its assembler won't accept). In fact, of course, Mingw
> with GCC 4.6 was also broken (e.g. <atomic> does not implement
> actually atomic operations), but it had been around long enough
> people had patched for it.

Do you know Which Boost libraries are broken with MingW using gcc 4.6.4
on up ?

I have tested some of my own things on trunk with MingW and gcc-4.7.0
and gcc.4.7.2 and they are testing OK, so I want to understand what
Boost code is broken.

>
> Mingw-w64 is absolutely fine though, and I very strongly recommend
> its use over traditional Mingw. Mingw-w64 was so trouble free that it
> just worked for me first time, which was quite a novel experience.

I will try this out also. Thanks !

[Niall Douglas]

On 21 Oct 2013 at 20:45, Edward Diener wrote:

> > Be aware that I found any Mingw after the one based on GCC 4.6.4 is
> > broken with Boost in various unhelpful ways (e.g. generating
> > assembler ops its assembler won't accept). In fact, of course, Mingw
> > with GCC 4.6 was also broken (e.g. <atomic> does not implement
> > actually atomic operations), but it had been around long enough
> > people had patched for it.
>
> Do you know Which Boost libraries are broken with MingW using gcc 4.6.4
> on up ?

Mingw with GCC 4.6.4 works okay. It's what my Jenkins CI uses for
Mingw pre-commit testing.

> I have tested some of my own things on trunk with MingW and gcc-4.7.0
> and gcc.4.7.2 and they are testing OK, so I want to understand what
> Boost code is broken.

I'm sure things will be different for different people, but there was
certainly a GCC 4.7.x based Mingw that forgot to feed -march=i486 to
its assembler, so if you did anything needing atomic instructions it
barfed.

I also found a showstopping ICE with my code on a GCC 4.8.x based
Mingw which kinda ruled it out for me. I went back to the GCC 4.6.4
based Mingw. It's reliable.

> > Mingw-w64 is absolutely fine though, and I very strongly recommend
> > its use over traditional Mingw. Mingw-w64 was so trouble free that it
> > just worked for me first time, which was quite a novel experience.
>
> I will try this out also. Thanks !

My only complaint with Mingw-w64 (I used the GCC 4.8 based version)
is that it dislikes the MSVC idiom of using {0} or {sizeof(struct)}
to zero initialise structures. It still compiles them, but it warns
and you get a ton of those warnings. You could disable just that
warning, but if I remember there are instances where you really do
want to see that warning. That said, they'd get lost in the noise on
Mingw. Other than that, my experience was good.

[Edward Diener]

On 10/21/2013 9:02 PM, Niall Douglas wrote:
> On 21 Oct 2013 at 20:45, Edward Diener wrote:
>
>>> Be aware that I found any Mingw after the one based on GCC 4.6.4 is
>>> broken with Boost in various unhelpful ways (e.g. generating
>>> assembler ops its assembler won't accept). In fact, of course, Mingw
>>> with GCC 4.6 was also broken (e.g. <atomic> does not implement
>>> actually atomic operations), but it had been around long enough
>>> people had patched for it.
>>
>> Do you know Which Boost libraries are broken with MingW using gcc 4.6.4
>> on up ?
>
> Mingw with GCC 4.6.4 works okay. It's what my Jenkins CI uses for
> Mingw pre-commit testing.

I don't see a gcc 4.6.4 on the MingW sourcforge site (
https://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/Version4/ ).
There is a 4.7.0-1 and 4.7.2-1 there, which I have used.

>
>> I have tested some of my own things on trunk with MingW and gcc-4.7.0
>> and gcc.4.7.2 and they are testing OK, so I want to understand what
>> Boost code is broken.
>
> I'm sure things will be different for different people, but there was
> certainly a GCC 4.7.x based Mingw that forgot to feed -march=i486 to
> its assembler, so if you did anything needing atomic instructions it
> barfed.

Is there any Boost library tests of which you know that displays this
problem ?

>
> I also found a showstopping ICE with my code on a GCC 4.8.x based
> Mingw which kinda ruled it out for me. I went back to the GCC 4.6.4
> based Mingw. It's reliable.

You should really report anything broken in MingW to their bug tracker
or mention it in their mailing list. It's possible that the versions on
sourceforge have already fixed the problem(s) you have seen. It's also
important that users of Boost and MingW understand what may be broken
using their particular release.

>
>>> Mingw-w64 is absolutely fine though, and I very strongly recommend
>>> its use over traditional Mingw. Mingw-w64 was so trouble free that it
>>> just worked for me first time, which was quite a novel experience.
>>
>> I will try this out also. Thanks !
>
> My only complaint with Mingw-w64 (I used the GCC 4.8 based version)
> is that it dislikes the MSVC idiom of using {0} or {sizeof(struct)}
> to zero initialise structures. It still compiles them, but it warns
> and you get a ton of those warnings. You could disable just that
> warning, but if I remember there are instances where you really do
> want to see that warning. That said, they'd get lost in the noise on
> Mingw. Other than that, my experience was good.

Does the Boost Build gcc toolset on Windows work correctly with
Mingw-w64 ? I have not had any problems with it using MingW itself with
Boost Build and don't want to commit to testing against it unless Boost
Build works with it.

[Niall Douglas]

On 21 Oct 2013 at 21:23, Edward Diener wrote:

> I don't see a gcc 4.6.4 on the MingW sourcforge site (
> https://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/Version4/ ).
> There is a 4.7.0-1 and 4.7.2-1 there, which I have used.

Sure, they're trying to get people off 4.6.x, which is indeed old but
trusty. I keep a tarball of it locally.

> Is there any Boost library tests of which you know that displays this
> problem ?

I had no reason to look. I only cared about AFIO, and therefore only
cared about its dependencies ASIO and Thread.

> > I also found a showstopping ICE with my code on a GCC 4.8.x based
> > Mingw which kinda ruled it out for me. I went back to the GCC 4.6.4
> > based Mingw. It's reliable.
>
> You should really report anything broken in MingW to their bug tracker
> or mention it in their mailing list. It's possible that the versions on
> sourceforge have already fixed the problem(s) you have seen. It's also
> important that users of Boost and MingW understand what may be broken
> using their particular release.

Mmm. You should look into how Mingw-w64 came about. There is a reason
they did a clean room reimplementation.

Also, me personally I have zero time for Mingw given MSVC is free and
Mingw binaries are not interoperable with MSVC ones. However Boost
peer review wants demonstrated portability, and for that alone I
delved into Mingw compatibility. Ordinarily I'd never touch it,
except to debug unhelpful MSVC error messages (and even there I
prefer clang-win).

> Does the Boost Build gcc toolset on Windows work correctly with
> Mingw-w64 ? I have not had any problems with it using MingW itself with
> Boost Build and don't want to commit to testing against it unless Boost
> Build works with it.

It worked fine for me. Simply make sure you bootstrap and run b2.exe
from inside a Mingw-w64 command box, or else fiddle with PATH to
insert Mingw-w64's bin directories for your environment. Otherwise
it'll pick up normal Mingw.

[Edward Diener]

On 10/21/2013 9:37 PM, Niall Douglas wrote:
> On 21 Oct 2013 at 21:23, Edward Diener wrote:
>
>> I don't see a gcc 4.6.4 on the MingW sourcforge site (
>> https://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/Version4/ ).
>> There is a 4.7.0-1 and 4.7.2-1 there, which I have used.
>
> Sure, they're trying to get people off 4.6.x, which is indeed old but
> trusty. I keep a tarball of it locally.

There is a 4.6.2-1 in the link above, but no 4.6.4. That's why I was
wondering why you are specifying 4.6.4.

>
>> Is there any Boost library tests of which you know that displays this
>> problem ?
>
> I had no reason to look. I only cared about AFIO, and therefore only
> cared about its dependencies ASIO and Thread.

Did you find any tests not working in ASIO and Thread when using gcc
4.7+ on up with MingW ? Or was it just in your own work with AFIO ?

>
>>> I also found a showstopping ICE with my code on a GCC 4.8.x based
>>> Mingw which kinda ruled it out for me. I went back to the GCC 4.6.4
>>> based Mingw. It's reliable.
>>
>> You should really report anything broken in MingW to their bug tracker
>> or mention it in their mailing list. It's possible that the versions on
>> sourceforge have already fixed the problem(s) you have seen. It's also
>> important that users of Boost and MingW understand what may be broken
>> using their particular release.
>
> Mmm. You should look into how Mingw-w64 came about. There is a reason
> they did a clean room reimplementation.

I will read about it. You are implying that the MingW-w64 people were
not happy with the quality of MingW. I will look for information about this.

>
> Also, me personally I have zero time for Mingw given MSVC is free and
> Mingw binaries are not interoperable with MSVC ones. However Boost
> peer review wants demonstrated portability, and for that alone I
> delved into Mingw compatibility. Ordinarily I'd never touch it,
> except to debug unhelpful MSVC error messages (and even there I
> prefer clang-win).

It sounds like you able to test clang under Windows using the MingW-w64
RTL and the Boost Build clang toolset.

>
>> Does the Boost Build gcc toolset on Windows work correctly with
>> Mingw-w64 ? I have not had any problems with it using MingW itself with
>> Boost Build and don't want to commit to testing against it unless Boost
>> Build works with it.
>
> It worked fine for me. Simply make sure you bootstrap and run b2.exe
> from inside a Mingw-w64 command box, or else fiddle with PATH to
> insert Mingw-w64's bin directories for your environment. Otherwise
> it'll pick up normal Mingw.

Got it. Thanks !

[Stephan T. Lavavej]

[Vladimir Prus]

> Well, I do have a Windows box, but last time I checked, there was a dozen
of flavours
> of MinGW. Stephan, can you point at whatever packages needs to be
downloaded to
> try?

You can grab my MinGW distro from: http://nuwen.net/mingw.html

It's just a self-extracting archive (no installer, doesn't modify your
system). Note that it's now based on mingw-w64, but the bootstrap.sh
problems affect both mingw-w64 and traditional mingw.org.

My build environment and build scripts are also available (again, no
installer): http://nuwen.net/mingw.html#build

I can give you excruciatingly detailed instructions if you want (but it
would take time to write up).

Thanks,
STL

[Jim Bell]

On 2013-10-21 8:23 PM, Edward Diener wrote:
>
>
> Does the Boost Build gcc toolset on Windows work correctly with
> Mingw-w64 ? I have not had any problems with it using MingW itself
> with Boost Build and don't want to commit to testing against it unless
> Boost Build works with it.

I didn't see this mentioned and probably goes without saying: the
regression matrix has MinGW-w64/gcc 4.4, 4.5, 4.6, 4.7, 4.8.

Also, though boostrap.sh is broken, this should work (under msys bash):

cd BOOST_ROOT/tools/build/v2/engine

./build.sh mingw

That should build BOOST_ROOT/tools/build/v2/engine/bin.ntx86/bjam.exe.

Hope that helps.

[Niall Douglas]

On 22 Oct 2013 at 0:21, Edward Diener wrote:

> > Sure, they're trying to get people off 4.6.x, which is indeed old but
> > trusty. I keep a tarball of it locally.
>
> There is a 4.6.2-1 in the link above, but no 4.6.4. That's why I was
> wondering why you are specifying 4.6.4.

Probably because I am going senile (I am also in Seattle, and
therefore unable to check the exact version, so I relied on my
obviously faulty memory).

> > I had no reason to look. I only cared about AFIO, and therefore only
> > cared about its dependencies ASIO and Thread.
>
> Did you find any tests not working in ASIO and Thread when using gcc
> 4.7+ on up with MingW ? Or was it just in your own work with AFIO ?

AFIO's tests failed. I didn't run anyone else's tests. The problems
came from not AFIO code though, but rather how AFIO instantiated
other people's code.

> > Also, me personally I have zero time for Mingw given MSVC is free and
> > Mingw binaries are not interoperable with MSVC ones. However Boost
> > peer review wants demonstrated portability, and for that alone I
> > delved into Mingw compatibility. Ordinarily I'd never touch it,
> > except to debug unhelpful MSVC error messages (and even there I
> > prefer clang-win).
>
> It sounds like you able to test clang under Windows using the MingW-w64
> RTL and the Boost Build clang toolset.

No, I usually use scons for build. I only used Boost.Build for AFIO
because I had to, and in truth Paul did almost all of the Jamfile
scripting.

[Niall Douglas]

On 21 Oct 2013 at 21:46, Stephan T. Lavavej wrote:

> It's just a self-extracting archive (no installer, doesn't modify your
> system). Note that it's now based on mingw-w64, but the bootstrap.sh
> problems affect both mingw-w64 and traditional mingw.org.

You are aware that bootstrap.bat can use Visual Studio, but the
output b2.exe can use mingw right?

In other words, bootstrapping can use any old compiler, it doesn't
have to match what b2.exe uses.

[niXman]

niXman 2013-10-22 04:07:

> P.S.
> I am sorry for offtopic, but can anybody tell me please, will
> boost.coroutine support MinGW in boost-1.55? On the bugtracker I saw
> the patch, will it be applied?
> Thanks.

ping?

[Ben Pope]

On 23/10/13 06:22, niXman wrote:
> niXman 2013-10-22 04:07:
>> P.S.
>> I am sorry for offtopic, but can anybody tell me please, will
>> boost.coroutine support MinGW in boost-1.55? On the bugtracker I saw
>> the patch, will it be applied?
>> Thanks.
>
> ping?

Your post would probably be more effective if instead of posting
off-topic, you started a new topic with a title like:

[coroutine] MinGW support in 1.55? (bug#)

Ben

[Dave Abrahams]

on Sun Oct 20 2013, Rene Rivera <grafikrobot-AT-gmail.com> wrote:

> Sorry if I hadn't gotten any time to look at MinGW building.. But I have
> had higher priority tasks (like getting a library into Boost, presenting a
> paper to LEWG, full time work, family, photo exhibition, etc.) to look into
> a patch I can't directly test, or apply.
>
> Sorry that sounded harsh..

It didn't.

> But so does your response Dave.

I know; I was being dramatic to get some attention to Stephan's patches.
I looked back at the posting history and he's done more than enough to
warrant at least someone *responding*.

[Dave Abrahams]

on Sun Oct 20 2013, Vladimir Prus <ghost-AT-cs.msu.su> wrote:

> On 21.10.2013 07:58, Dave Abrahams wrote:
>>
>> on Sat Oct 19 2013, "Stephan T. Lavavej" <stl-AT-nuwen.net> wrote:
>>
>>> Hi,
>>>
>
>>> For months, I've been pinging the boost-build list about bootstrap.sh being
>>> completely broken for MinGW, with no response.
>>>
>>> As the 1.55.0 branch is closing in just a week, it would be wonderful if
>>> somebody could look at and apply my two patches that are ready to go:
>>> http://lists.boost.org/boost-build/2013/10/27025.php
>>>
>>> Note that they will fix this: https://svn.boost.org/trac/boost/ticket/8762
>>
>> If the maintainers are unresponsive to something like this it would seem
>> to argue for giving up on Boost.Build ASAP.
>
> We might want to first give up on git transition, given that after all these
> years you are still *discussing* what is the appropriate workflow?

As far as I can tell Git is totally irrelevant to the question.

> And on the mingw topic, I might have missed something, but I think the major
> issue is still mingw vs. gcc naming inconsistency between bootstrap.sh
> and b2 proper - which is ugly, but not quite a showstopper?

I have no idea what the technical issues are. We have a broken
relationship between maintainers and users here.

--
Dave Abrahams

[Vladimir Prus]

On 22.10.2013 08:46, Stephan T. Lavavej wrote:
> [Vladimir Prus]
>> Well, I do have a Windows box, but last time I checked, there was a dozen
> of flavours
>> of MinGW. Stephan, can you point at whatever packages needs to be
> downloaded to
>> try?
>
> You can grab my MinGW distro from: http://nuwen.net/mingw.html
>
> It's just a self-extracting archive (no installer, doesn't modify your
> system). Note that it's now based on mingw-w64, but the bootstrap.sh
> problems affect both mingw-w64 and traditional mingw.org.

Stephan,

suppose I was living in a cave, and all I've got is Windows XP 32-bit. If I try
your archive I get error that the binaries are 64-bit bits. Does that mean
I'm out of luck? Or I can use either 'standard' mingw or build your distribution
for 32-bits?


But then, it seems like your second and third patches affect only mingw; you know better
whether they are good or not. Can you just commit those, and I'll ask release managers
about merging to release branch.


Thanks,
Volodya

[Stephan T. Lavavej]

[Vladimir Prus]

> suppose I was living in a cave, and all I've got is Windows XP 32-bit. If
I try
> your archive I get error that the binaries are 64-bit bits. Does that mean
> I'm out of luck? Or I can use either 'standard' mingw or build your
distribution
> for 32-bits?

My distro 10.4 (see the big table at the bottom of my page) was 32-bit.
It'll probably work on XP, but I can't guarantee that.

P.S. x86 is dead :->

> But then, it seems like your second and third patches affect only mingw;
you know better
> whether they are good or not. Can you just commit those, and I'll ask
release managers
> about merging to release branch.

I do not have commit access, which is why I've been asking for somebody to
check them in. My (non-hacktrocity) patches definitely fix both mingw.org
(32-bit) and mingw-w64 (64-bit), and I am confident that they don't affect
other platforms. (In any event, non-mingw platforms actually receive
testing.)

Thanks,
STL

[niXman]

> I do not have commit access, which is why I've been asking for somebody
> to
> check them in. My (non-hacktrocity) patches definitely fix both
> mingw.org
> (32-bit) and mingw-w64 (64-bit), and I am confident that they don't
> affect
> other platforms. (In any event, non-mingw platforms actually receive
> testing.)

I have commit access on mingw-w64. What patch are you referring to?


--
Regards, niXman
___________________________________________________
Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:

http://sourceforge.net/projects/mingw-w64/
___________________________________________________
Another online IDE: http://liveworkspace.org/

[Beman Dawes]

On Sat, Oct 26, 2013 at 4:39 AM, Stephan T. Lavavej <s...@nuwen.net> wrote:

I do not have commit access...
>

If you would like write access, just let me know.

--Beman

[niXman]

> If you would like write access, just let me know.

I thought that it was about the commit access for mingw-w64. Sorry.

--
Regards, niXman
___________________________________________________
Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:
http://sourceforge.net/projects/mingw-w64/
___________________________________________________
Another online IDE: http://liveworkspace.org/

[Stephan T. Lavavej]

[Beman Dawes]

> If you would like write access, just let me know.

Thanks, but that's not necessary - I just need somebody to commit build.jam and build.sh from http://nuwen.net/stuff/boost-bootstrap.patch so I can stop hacking Boost. :->

STL

[Eric Niebler]

On 10/26/2013 1:15 PM, Stephan T. Lavavej wrote:
> [Beman Dawes]
>> If you would like write access, just let me know.
>
> Thanks, but that's not necessary - I just need somebody to commit build.jam and build.sh from http://nuwen.net/stuff/boost-bootstrap.patch so I can stop hacking Boost. :->

Committed to trunk, https://svn.boost.org/trac/boost/changeset/86460.
Stephan, can you have a look at the changeset and let me know if
everything looks ok?

I don't have MinGW installed. I'd love it if someone tried:

> $ ./bootstrap.sh --with-toolset=mingw

...before I merge this to release. Couldn't hurt to try other platforms,
too.

Thanks, Stephan!

--
Eric Niebler
Boost.org
http://www.boost.org

[niXman]

> I don't have MinGW installed. I'd love it if someone tried:
>
>> $ ./bootstrap.sh --with-toolset=mingw
>
> ...before I merge this to release. Couldn't hurt to try other
> platforms,
> too.

Cygwin-x86_64 & gcc-4.8.2-x86_64:

gcc.compile.asm
bin.v2/libs/context/build/gcc-4.8.2/release/link-static/runtime-link-static/threading-multi/asm/make_x86_64_sysv_elf_gas.o
libs/context/src/asm/make_x86_64_sysv_elf_gas.S: Assembler messages:
libs/context/src/asm/make_x86_64_sysv_elf_gas.S:43: Warning: .type
pseudo-op used outside of .def/.endef ignored.
libs/context/src/asm/make_x86_64_sysv_elf_gas.S:43: Error: junk at end
of line, first unrecognized character is `m'
libs/context/src/asm/make_x86_64_sysv_elf_gas.S:73: Warning: .size
pseudo-op used outside of .def/.endef ignored.
libs/context/src/asm/make_x86_64_sysv_elf_gas.S:73: Error: junk at end
of line, first unrecognized character is `m'

"g++" -x assembler-with-cpp -O3 -finline-functions -Wno-inline -Wall
-DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o
"bin.v2/libs/context/build/gcc-4.8.2/release/link-static/runtime-link-static/threading-multi/asm/make_x86_64_sysv_elf_gas.o" "libs/context/src/asm/make_x86_64_sysv_elf_gas.S"

...failed gcc.compile.asm
bin.v2/libs/context/build/gcc-4.8.2/release/link-static/runtime-link-static/threading-multi/asm/make_x86_64_sysv_elf_gas.o...
gcc.compile.asm
bin.v2/libs/context/build/gcc-4.8.2/release/link-static/runtime-link-static/threading-multi/asm/jump_x86_64_sysv_elf_gas.o
libs/context/src/asm/jump_x86_64_sysv_elf_gas.S: Assembler messages:
libs/context/src/asm/jump_x86_64_sysv_elf_gas.S:43: Warning: .type
pseudo-op used outside of .def/.endef ignored.
libs/context/src/asm/jump_x86_64_sysv_elf_gas.S:43: Error: junk at end
of line, first unrecognized character is `j'
libs/context/src/asm/jump_x86_64_sysv_elf_gas.S:82: Warning: .size
pseudo-op used outside of .def/.endef ignored.
libs/context/src/asm/jump_x86_64_sysv_elf_gas.S:82: Error: junk at end
of line, first unrecognized character is `j'

"g++" -x assembler-with-cpp -O3 -finline-functions -Wno-inline -Wall
-DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o
"bin.v2/libs/context/build/gcc-4.8.2/release/link-static/runtime-link-static/threading-multi/asm/jump_x86_64_sysv_elf_gas.o" "libs/context/src/asm/jump_x86_64_sysv_elf_gas.S"

...failed gcc.compile.asm
bin.v2/libs/context/build/gcc-4.8.2/release/link-static/runtime-link-static/threading-multi/asm/jump_x86_64_sysv_elf_gas.o...
...skipped
<pbin.v2/libs/context/build/gcc-4.8.2/release/link-static/runtime-link-static/threading-multi>libboost_context.a(clean) for lack of <pbin.v2/libs/context/build/gcc-4.8.2/release/link-static/runtime-link-static/threading-multi>asm/make_x86_64_sysv_elf_gas.o...
...skipped
<pbin.v2/libs/context/build/gcc-4.8.2/release/link-static/runtime-link-static/threading-multi>libboost_context.a for lack of <pbin.v2/libs/context/build/gcc-4.8.2/release/link-static/runtime-link-static/threading-multi>asm/make_x86_64_sysv_elf_gas.o...
...skipped <p/d/msys64-dev/home/niXman/boost/lib>libboost_context.a for
lack of
<pbin.v2/libs/context/build/gcc-4.8.2/release/link-static/runtime-link-static/threading-multi>libboost_context.a...
gcc.compile.c++
bin.v2/libs/log/build/gcc-4.8.2/release/link-static/log-api-unix/runtime-link-static/threading-multi/date_time_format_parser.o
In file included from ./boost/proto/traits.hpp:24:0,
from ./boost/proto/matches.hpp:42,
from ./boost/phoenix/core/domain.hpp:12,
from ./boost/phoenix/core/actor.hpp:17,
from ./boost/phoenix/core.hpp:15,
from ./boost/spirit/include/phoenix_core.hpp:16,
from ./boost/spirit/home/support/terminal.hpp:16,
from
./boost/spirit/home/support/common_terminals.hpp:15,
from ./boost/spirit/home/karma/numeric/uint.hpp:18,
from ./boost/spirit/include/karma_uint.hpp:16,
from
D:\msys64-dev\home\niXman\boost_1_54_0\libs\log\src\date_time_format_parser.cpp:19:
./boost/math/tools/promotion.hpp: In instantiation of ‘struct
boost::math::tools::promote_args<long double, float, float, float,
float, float>’:
./boost/math/special_functions/sign.hpp:114:50: required from ‘int
boost::math::signbit(T) [with T = long double]’
./boost/spirit/home/support/detail/sign.hpp:47:40: required from ‘bool
boost::spirit::detail::signbit(T) [with T = long double]’
./boost/spirit/home/karma/numeric/detail/numeric_utils.hpp:130:47:
required from here
./boost/math/tools/promotion.hpp:141:10: error: invalid application of
‘sizeof’ to incomplete type ‘boost::STATIC_ASSERTION_FAILURE<false>’
BOOST_STATIC_ASSERT((0 == ::boost::is_same<type, long
double>::value));
^

"g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall
-mthreads -Wno-unused-local-typedefs -Wno-unused-but-set-variable
-Wno-sign-compare -Wno-unknown-pragmas -fno-strict-aliasing
-ftemplate-depth-1024 -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_STATIC_LINK=1
-DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_LOG_BUILDING_THE_LIB=1
-DBOOST_LOG_USE_AVX2 -DBOOST_LOG_USE_NATIVE_SYSLOG -DBOOST_LOG_USE_SSSE3
-DBOOST_LOG_WITHOUT_EVENT_LOG -DBOOST_SPIRIT_USE_PHOENIX_V3=1
-DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_SYSTEM_STATIC_LINK=1
-DBOOST_THREAD_BUILD_LIB=1 -DBOOST_THREAD_DONT_USE_CHRONO=1
-DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_LIB=1 -DDATE_TIME_INLINE
-DNDEBUG -I"." -c -o
"D:\msys64-dev\home\niXman\boost_1_54_0\bin.v2\libs\log\build\gcc-4.8.2\release\link-static\log-api-unix\runtime-link-static\threading-multi\date_time_format_parser.o" "D:\msys64-dev\home\niXman\boost_1_54_0\libs\log\src\date_time_format_parser.cpp"

...failed gcc.compile.c++
bin.v2/libs/log/build/gcc-4.8.2/release/link-static/log-api-unix/runtime-link-static/threading-multi/date_time_format_parser.o...
gcc.compile.c++
bin.v2/libs/log/build/gcc-4.8.2/release/link-static/log-api-unix/runtime-link-static/threading-multi/named_scope_format_parser.o
In file included from ./boost/proto/traits.hpp:24:0,
from ./boost/proto/matches.hpp:42,
from ./boost/phoenix/core/domain.hpp:12,
from ./boost/phoenix/core/actor.hpp:17,
from ./boost/phoenix/core.hpp:15,
from ./boost/spirit/include/phoenix_core.hpp:16,
from ./boost/spirit/home/support/terminal.hpp:16,
from
./boost/spirit/home/support/common_terminals.hpp:15,
from ./boost/spirit/home/karma/numeric/uint.hpp:18,
from ./boost/spirit/include/karma_uint.hpp:16,
from
D:\msys64-dev\home\niXman\boost_1_54_0\libs\log\src\named_scope_format_parser.cpp:22:
./boost/math/tools/promotion.hpp: In instantiation of ‘struct
boost::math::tools::promote_args<long double, float, float, float,
float, float>’:
./boost/math/special_functions/sign.hpp:114:50: required from ‘int
boost::math::signbit(T) [with T = long double]’
./boost/spirit/home/support/detail/sign.hpp:47:40: required from ‘bool
boost::spirit::detail::signbit(T) [with T = long double]’
./boost/spirit/home/karma/numeric/detail/numeric_utils.hpp:130:47:
required from here
./boost/math/tools/promotion.hpp:141:10: error: invalid application of
‘sizeof’ to incomplete type ‘boost::STATIC_ASSERTION_FAILURE<false>’
BOOST_STATIC_ASSERT((0 == ::boost::is_same<type, long
double>::value));
^

"g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall
-mthreads -Wno-unused-local-typedefs -Wno-unused-but-set-variable
-Wno-sign-compare -Wno-unknown-pragmas -fno-strict-aliasing
-ftemplate-depth-1024 -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_STATIC_LINK=1
-DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_LOG_BUILDING_THE_LIB=1
-DBOOST_LOG_USE_AVX2 -DBOOST_LOG_USE_NATIVE_SYSLOG -DBOOST_LOG_USE_SSSE3
-DBOOST_LOG_WITHOUT_EVENT_LOG -DBOOST_SPIRIT_USE_PHOENIX_V3=1
-DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_SYSTEM_STATIC_LINK=1
-DBOOST_THREAD_BUILD_LIB=1 -DBOOST_THREAD_DONT_USE_CHRONO=1
-DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_LIB=1 -DDATE_TIME_INLINE
-DNDEBUG -I"." -c -o
"D:\msys64-dev\home\niXman\boost_1_54_0\bin.v2\libs\log\build\gcc-4.8.2\release\link-static\log-api-unix\runtime-link-static\threading-multi\named_scope_format_parser.o" "D:\msys64-dev\home\niXman\boost_1_54_0\libs\log\src\named_scope_format_parser.cpp"

...failed gcc.compile.c++
bin.v2/libs/log/build/gcc-4.8.2/release/link-static/log-api-unix/runtime-link-static/threading-multi/named_scope_format_parser.o...
...skipped
<pbin.v2/libs/log/build/gcc-4.8.2/release/link-static/log-api-unix/runtime-link-static/threading-multi>libboost_log.a(clean) for lack of <pbin.v2/libs/log/build/gcc-4.8.2/release/link-static/log-api-unix/runtime-link-static/threading-multi>date_time_format_parser.o...
...skipped
<pbin.v2/libs/log/build/gcc-4.8.2/release/link-static/log-api-unix/runtime-link-static/threading-multi>libboost_log.a for lack of <pbin.v2/libs/log/build/gcc-4.8.2/release/link-static/log-api-unix/runtime-link-static/threading-multi>date_time_format_parser.o...
...skipped <p/d/msys64-dev/home/niXman/boost/lib>libboost_log.a for lack
of
<pbin.v2/libs/log/build/gcc-4.8.2/release/link-static/log-api-unix/runtime-link-static/threading-multi>libboost_log.a...
...failed updating 4 targets...
...skipped 6 targets...

--
Regards, niXman
___________________________________________________
Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:
http://sourceforge.net/projects/mingw-w64/
___________________________________________________
Another online IDE: http://liveworkspace.org/

_______________________________________________

[Oliver Kowalke]

you are using the zip archive containing files which have CRLF at the
end-of-line.Try using the bz2-archive.

[niXman]

Oliver Kowalke писал 2013-10-27 16:35:

> you are using the zip archive containing files which have CRLF at the
> end-of-line.Try using the bz2-archive.

No, I use bz2 archive and in
'libs/context/src/asm/make_x86_64_sysv_elf_gas.S' file LF is used as
EOL.

Now I'll try to build boost-trunk with i686-mingw-w64 &
x86_64-mingw-w64. I'll report about the result.

--
Regards, niXman
___________________________________________________
Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:
http://sourceforge.net/projects/mingw-w64/
___________________________________________________
Another online IDE: http://liveworkspace.org/

_______________________________________________

[Oliver Kowalke]

2013/10/27 niXman <i.ni...@autistici.org>

> Oliver Kowalke писал 2013-10-27 16:35:
>
> you are using the zip archive containing files which have CRLF at the
>> end-of-line.Try using the bz2-archive.
>>
>

> No, I use bz2 archive and in 'libs/context/src/asm/make_**x86_64_sysv_elf_gas.S'

> file LF is used as EOL.
>
> Now I'll try to build boost-trunk with i686-mingw-w64 & x86_64-mingw-w64.
> I'll report about the result
>

we have had this issue several times in the past - it was each time CRLF at
the end of the lines

[niXman]

niXman 2013-10-27 17:39:

> Now I'll try to build boost-trunk with i686-mingw-w64 &
> x86_64-mingw-w64. I'll report about the result.

Hmm..

D:\boost-trunk>g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=d:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.8.2/lto-w
rapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-4.8.2/configure
--host=x86_64-w64-mingw32 --bu
ild=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64
--with-sysr
oot=/tmp/x86_64-482-posix-seh-rt_v3-r0/mingw64 --enable-shared
--enable-static -
-disable-multilib --enable-languages=ada,c,c++,fortran,objc,obj-c++,lto
--enable
-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-lto
--enabl
e-graphite --enable-checking=release --enable-fully-dynamic-string
--enable-vers
ion-specific-runtime-libs --disable-isl-version-check
--disable-cloog-version-ch
eck --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap
--disab
le-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symve
rs --with-gnu-as --with-gnu-ld --with-arch=nocona --with-tune=core2
--with-libic
onv --with-system-zlib
--with-gmp=/tmp/prerequisites/x86_64-w64-mingw32-static -
-with-mpfr=/tmp/prerequisites/x86_64-w64-mingw32-static
--with-mpc=/tmp/prerequi
sites/x86_64-w64-mingw32-static
--with-isl=/tmp/prerequisites/x86_64-w64-mingw32
-static --with-cloog=/tmp/prerequisites/x86_64-w64-mingw32-static
--enable-cloog
-backend=isl --with-pkgversion='rev0, Built by MinGW-W64 project'
--with-bugurl=
http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe
-I/tmp/x86_64-482-po
six-seh-rt_v3-r0/mingw64/opt/include
-I/tmp/prerequisites/x86_64-zlib-static/inc
lude -I/tmp/prerequisites/x86_64-w64-mingw32-static/include'
CXXFLAGS='-O2 -pipe
-I/tmp/x86_64-482-posix-seh-rt_v3-r0/mingw64/opt/include
-I/tmp/prerequisites/x
86_64-zlib-static/include
-I/tmp/prerequisites/x86_64-w64-mingw32-static/include
' CPPFLAGS= LDFLAGS='-pipe
-L/tmp/x86_64-482-posix-seh-rt_v3-r0/mingw64/opt/lib
-L/tmp/prerequisites/x86_64-zlib-static/lib
-L/tmp/prerequisites/x86_64-w64-ming
w32-static/lib '
Thread model: posix
gcc version 4.8.2 (rev0, Built by MinGW-W64 project)

(compiler in PATH)


D:\boost-trunk>bootstrap.bat mingw
Building Boost.Build engine
'"VCVARS32.BAT"' is not recognized as an internal or external command,
operable program or batch file.
The system cannot find the batch label specified - Test_Option
'"VCVARS32.BAT"' is not recognized as an internal or external command,
operable program or batch file.
'"VCVARS32.BAT"' is not recognized as an internal or external command,
operable program or batch file.
'cl' is not recognized as an internal or external command,
operable program or batch file.

Failed to build Boost.Build engine.
Please consult bootstrap.log for furter diagnostics.

You can try to obtain a prebuilt binary from

http://sf.net/project/showfiles.php?group_id=7586&package_id=72941

Also, you can file an issue at http://svn.boost.org
Please attach bootstrap.log in that case.

D:\boost-trunk>bootstrap.bat --with-toolset=mingw
Building Boost.Build engine
'"VCVARS32.BAT"' is not recognized as an internal or external command,
operable program or batch file.
The system cannot find the batch label specified - Test_Option
'"VCVARS32.BAT"' is not recognized as an internal or external command,
operable program or batch file.
The system cannot find the batch label specified - Test_Option
'"VCVARS32.BAT"' is not recognized as an internal or external command,
operable program or batch file.
'"VCVARS32.BAT"' is not recognized as an internal or external command,
operable program or batch file.
'cl' is not recognized as an internal or external command,
operable program or batch file.

Failed to build Boost.Build engine.
Please consult bootstrap.log for furter diagnostics.

You can try to obtain a prebuilt binary from

http://sf.net/project/showfiles.php?group_id=7586&package_id=72941

Also, you can file an issue at http://svn.boost.org
Please attach bootstrap.log in that case.



What I am doing wrongly?

[Oliver Kowalke]

> What I am doing wrongly?
>

no idea - I' don't use mingw, but the code compiles for several mingw
versions -> see
http://www.boost.org/development/tests/trunk/developer/context.html

[Stephan T. Lavavej]

[Eric Niebler]

> Committed to trunk, https://svn.boost.org/trac/boost/changeset/86460.
> Stephan, can you have a look at the changeset and let me know if
> everything looks ok?

Yay, thank you! The diff looks good to me.

> I don't have MinGW installed. I'd love it if someone tried:
> > $ ./bootstrap.sh --with-toolset=mingw
> ...before I merge this to release.

I believe this will still explode due to the first problem I identified -
different parts of Boost.Build can't agree on whether MinGW should be called
gcc or mingw. Last I checked, no permutation of command-line arguments to
bootstrap.sh and b2.exe could avoid this.

[niXman]

> What I am doing wrongly?

One of the problems appears to be that you're attempting to build
Boost.Context with only MinGW installed (no VC). This is broken due to
https://svn.boost.org/trac/boost/ticket/7262 . Context's maintainer has
cited a MinGW linker bug and has refused to work around it. (I don't know
whether this bug has been reported to binutils.) Boost.Build does not
auto-detect this situation and disable Context, so you must pass
--without-context --without-coroutine in order to avoid this (Coroutine
depends on Context).

Additionally, if you are building with mingw-w64, you will want to pass
pch=off in order to avoid having Boost.Math trigger a mingw-w64 PCH bug
(unless it has been fixed in the last month or so). See
http://lists.boost.org/Archives/boost/2013/07/205244.php for that thread.

I don't know what's happening with the static assertion you're getting in
Boost.Math. That might have appeared since 1.54.0, in which case I wouldn't
have seen it yet.

STL

[Vladimir Prus]

On 26.10.2013 12:39, Stephan T. Lavavej wrote:
> [Vladimir Prus]
>> >suppose I was living in a cave, and all I've got is Windows XP 32-bit. If
> I try
>> >your archive I get error that the binaries are 64-bit bits. Does that mean
>> >I'm out of luck? Or I can use either 'standard' mingw or build your
> distribution
>> >for 32-bits?
> My distro 10.4 (see the big table at the bottom of my page) was 32-bit.
> It'll probably work on XP, but I can't guarantee that.

I've tried 10.4 and it works. Now time for next level of confusion - your patch touches bootstrap.sh but
I don't really know how to execute it. Running it directly as "bootstrap.sh" obviously does not work,
and I don't see any "sh" binary for "sh bootstrap.sh" to work. I notice that bootstrap.bat does not
work either, even though I though it should pick mingw from PATH.

So - what ways of using mingw do we want to have supported?

- Volodya

[niXman]

niXman писал 2013-10-27 18:15:

bootstrap.bat works fine with MinGW for boost 1.51,1.52,1.53,1.54.
But not for current trunk.

Ideas?

[Stephan T. Lavavej]

[Vladimir Prus]

> Now time for next level of confusion - your patch touches bootstrap.sh
> but I don't really know how to execute it. Running it directly as
> "bootstrap.sh" obviously does not work, and I don't see any "sh" binary
> for "sh bootstrap.sh" to work.

It has to be run in MSYS, as I explained at
http://nuwen.net/mingw.html#build . Here are slightly more detailed
instructions:

0. You're running x86, so you need 7-Zip's x86 7za.exe, which I removed
between distro 10.3 and 10.4. Instead of downgrading to distro 10.3, you can
download it from http://www.7-zip.org/download.html . It's the "7-Zip
Command Line Version". Just put 7za.exe in C:\MinGW\bin, it's a stand-alone
executable.

1. Download http://nuwen.net/files/mingw/msys-10.4.7z
2. Extract it.
3. Run my extract.bat (it's a one-liner).
4. Run msys.bat to launch MSYS.
5. See C:\MinGW\scripts-10.4\boost.sh for my Boost build script (the patches
I use are also in that directory).

WARNING: Read my "Important notes" in #build, which explain the directory
assumptions. In particular, you should "run" my build script by copying and
pasting one line at a time into MSYS and carefully watching the output.

STL

P.S. x86 is dead! :->

[Eric Niebler]

On 10/28/2013 12:58 AM, niXman wrote:
> bootstrap.bat works fine with MinGW for boost 1.51,1.52,1.53,1.54.
> But not for current trunk.
>
> Ideas?

I honestly have no idea, and this is a little disturbing. I'm tempted to
back Stephan's changes out of trunk, unless Stephan has some ideas for
how to proceed.

--
Eric Niebler
Boost.org
http://www.boost.org

[Stephan T. Lavavej]

[niXman]

> bootstrap.bat works fine with MinGW for boost 1.51,1.52,1.53,1.54.
> But not for current trunk.

[Eric Niebler]

> I honestly have no idea, and this is a little disturbing. I'm tempted to
> back Stephan's changes out of trunk, unless Stephan has some ideas for
> how to proceed.

This should be totally unrelated. niXman's bootstrap.bat invocations are trying to find VCVARS32.BAT for some reason. My changes merely emit backslashes for paths in build.jam. (The use of pathnt.c for mingw in build.sh and pathunix.c for not-mingw is unquestionably correct, and should also be completely disconnected from the bootstrap.bat machinery.)

It would be nice if niXman could sync to before checkin 86460 in order to exonerate it.

STL

[Nathan Ridge]

> Now time for next level of confusion - your patch touches bootstrap.sh but
> I don't really know how to execute it. Running it directly as "bootstrap.sh" obviously does not work,
> and I don't see any "sh" binary for "sh bootstrap.sh" to work. I notice that bootstrap.bat does not
> work either, even though I though it should pick mingw from PATH.
>
> So - what ways of using mingw do we want to have supported?

I have a very basic question: what is the difference between bootstrap.bat
and bootstrap.sh in terms of what they do? Obviously one is designed to
be run in cmd.exe and the other in a Unix shell (which on Windows can
be provided by Cygwin or MSYS or something else), but does it matter
which one I use?

Thanks,
Nate

[niXman]

Stephan T. Lavavej 2013-10-28 21:39:

> It would be nice if niXman could sync to before checkin 86460 in order
> to exonerate it.

The same error.


D:\boost-trunk>svn info
...
Revision: 86459
...

D:\boost-trunk>bootstrap.bat mingw
Building Boost.Build engine
'"VCVARS32.BAT"' is not recognized as an internal or external command,
operable program or batch file.
The system cannot find the batch label specified - Test_Option
'"VCVARS32.BAT"' is not recognized as an internal or external command,
operable program or batch file.
'"VCVARS32.BAT"' is not recognized as an internal or external command,
operable program or batch file.
'cl' is not recognized as an internal or external command,
operable program or batch file.

Failed to build Boost.Build engine.
Please consult bootstrap.log for furter diagnostics.

You can try to obtain a prebuilt binary from

http://sf.net/project/showfiles.php?group_id=7586&package_id=72941

Also, you can file an issue at http://svn.boost.org
Please attach bootstrap.log in that case.

Hmm...

--
Regards, niXman
___________________________________________________
Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:
http://sourceforge.net/projects/mingw-w64/
___________________________________________________
Another online IDE: http://liveworkspace.org/

[Eric Niebler]

On 10/28/2013 1:24 PM, niXman wrote:
> Stephan T. Lavavej 2013-10-28 21:39:
>> It would be nice if niXman could sync to before checkin 86460 in order
>> to exonerate it.
>
> The same error.

<snip>

> D:\boost-trunk>bootstrap.bat mingw

Forgive the stupid question, but shouldn't you be using bootstrap.sh
from the MSYS prompt instead of bootstrap.bat from the DOS prompt?

Anyway, I installed MinGW following Stephan's instructions, and found
that bootstrap.sh still doesn't work on trunk, but due to this:

> ###
> ### Using 'mingw' toolset.
> ###
> rm -rf bootstrap
> mkdir bootstrap
> gcc -DNT -o bootstrap/jam0 command.c compile.c constants.c debug.c execcmd.c frames.c function.c glob.c hash.c hdrmacro.c headech.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c class.c cwd.c native.c md5.c w32_getreg.c modules/builtins.c: In function 'builtin_readlink':
> builtins.c:1879:39: error: 'FSCTL_GET_REPARSE_POINT' undeclared (first use in this function)
> builtins.c:1879:39: note: each undeclared identifier is reported only once for each function it appears in

So it looks like something is still broken. Stephan?

--
Eric Niebler
Boost.org
http://www.boost.org

[niXman]

Eric Niebler 2013-10-29 01:22:

> Forgive the stupid question, but shouldn't you be using bootstrap.sh
> from the MSYS prompt instead of bootstrap.bat from the DOS prompt?

Why should I install the posix emulator only in order to build boost?
I use boost starting from 1.41 version, and have always built it using
bootstrap.bat

--
Regards, niXman
___________________________________________________
Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:
http://sourceforge.net/projects/mingw-w64/
___________________________________________________
Another online IDE: http://liveworkspace.org/

[Steven Watanabe]

AMDG

On 10/28/2013 02:22 PM, Eric Niebler wrote:
>
>> ###
>> ### Using 'mingw' toolset.
>> ###
>> rm -rf bootstrap
>> mkdir bootstrap
>> gcc -DNT -o bootstrap/jam0 command.c compile.c constants.c debug.c execcmd.c frames.c function.c glob.c hash.c hdrmacro.c headech.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c class.c cwd.c native.c md5.c w32_getreg.c modules/builtins.c: In function 'builtin_readlink':
>> builtins.c:1879:39: error: 'FSCTL_GET_REPARSE_POINT' undeclared (first use in this function)
>> builtins.c:1879:39: note: each undeclared identifier is reported only once for each function it appears in
>
> So it looks like something is still broken. Stephan?
>

The problem is that MinGW's windows.h is only a
subset of the real windows.h. This is part
of the code used to handle symlinks for the
git transition. I didn't test it on mingw.

In Christ,
Steven Watanabe

[niXman]

Eric Niebler 2013-10-29 01:22:

> builtins.c:1879:39: error: 'FSCTL_GET_REPARSE_POINT' undeclared (first
> use in this function)

'FSCTL_GET_REPARSE_POINT' is defined in the 'winioctl.h' file.
(http://msdn.microsoft.com/en-us/library/windows/desktop/aa364571(v=vs.85).aspx)

The documentation says that this header('winioctl.h') must be included
into 'windows.h', but in mingw-w64:windows.h it's not so.
We will fix this.

--
Regards, niXman
___________________________________________________
Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:
http://sourceforge.net/projects/mingw-w64/
___________________________________________________
Another online IDE: http://liveworkspace.org/

[Eric Niebler]

On 10/28/2013 2:52 PM, niXman wrote:
> Eric Niebler 2013-10-29 01:22:
>> Forgive the stupid question, but shouldn't you be using bootstrap.sh
>> from the MSYS prompt instead of bootstrap.bat from the DOS prompt?
>
> Why should I install the posix emulator only in order to build boost?
> I use boost starting from 1.41 version, and have always built it using
> bootstrap.bat

Why use the posix emulator? Why use mingw at all? I confess to be
totally n00b about this stuff, but if you want to build boost using gcc
on windows, it would seem to make sense to me to install mingw and then
do things The Mingw Way, no?

Some observations:

1) There is a bootstrap.bat both at $BOOST_ROOT and and
$BOOST_ROOT/tools/build/v2. They are different. Are we all taking about
the same one? Which one should I be using (and why do we have two)?

2) Stephan's mingw distribution doesn't include gcc. I'm wondering how
he expects things to work.

Confused.

--
Eric Niebler
Boost.org
http://www.boost.org

[niXman]

Eric Niebler 2013-10-29 02:41:

> Why use the posix emulator? Why use mingw at all? I confess to be
> totally n00b about this stuff, but if you want to build boost using gcc
> on windows, it would seem to make sense to me to install mingw and then
> do things The Mingw Way, no?

Tne MinGW/MinGW-w64 and MSYS are absolutely different projects and there
is no tie-up between them.
The MinGW/MinGW-w64 is native win32/win64 compiler, and MSYS is posix
emulator.

In order to build win32/win64 native applications it is not necessarily
to install MSYS.

> Some observations:
>
> 1) There is a bootstrap.bat both at $BOOST_ROOT and and
> $BOOST_ROOT/tools/build/v2. They are different. Are we all taking about
> the same one? Which one should I be using (and why do we have two)?

I speek about '$BOOST_ROOT/bootstrap.bat'.

--
Regards, niXman
___________________________________________________
Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:
http://sourceforge.net/projects/mingw-w64/
___________________________________________________
Another online IDE: http://liveworkspace.org/

[Nathan Ridge]

>> Why should I install the posix emulator only in order to build boost?
>> I use boost starting from 1.41 version, and have always built it using
>> bootstrap.bat
>
> Why use the posix emulator? Why use mingw at all? I confess to be
> totally n00b about this stuff, but if you want to build boost using gcc
> on windows, it would seem to make sense to me to install mingw and then
> do things The Mingw Way, no?

MinGW and MSYS are two different things.

MinGW is a Windows port of gcc.

MSYS is a Windows port of just enough of a Unix environment (shell,
coreutils, autotools and such) to build projects that use an autotools
(configure+make) build system on Windows.

The only relation between the two is:
 - MSYS, and the original (and still most commonly used) variant of
   MinGW, are made by the same group of people (MinGW.org)
 - People who port Unix programs to Windows, or who just like
   working in a Unix environment and need to work on Windows,
   often use the two together.

However, you don't have to use the two together, and many don't.

> 2) Stephan's mingw distribution doesn't include gcc. I'm wondering how
> he expects things to work.

Huh? When I extract http://nuwen.net/files/mingw/mingw-11.2.exe, I
see a MinGW/bin/gcc.exe.

Regards,
Nate

[Eric Niebler]

On 10/28/2013 4:14 PM, Nathan Ridge wrote:
>>> Why should I install the posix emulator only in order to build boost?
>>> I use boost starting from 1.41 version, and have always built it using
>>> bootstrap.bat
>>
>> Why use the posix emulator? Why use mingw at all? I confess to be
>> totally n00b about this stuff, but if you want to build boost using gcc
>> on windows, it would seem to make sense to me to install mingw and then
>> do things The Mingw Way, no?
>
> MinGW and MSYS are two different things.
>
> MinGW is a Windows port of gcc.
>
> MSYS is a Windows port of just enough of a Unix environment (shell,
> coreutils, autotools and such) to build projects that use an autotools
> (configure+make) build system on Windows.
>
> The only relation between the two is:
> - MSYS, and the original (and still most commonly used) variant of
> MinGW, are made by the same group of people (MinGW.org)
> - People who port Unix programs to Windows, or who just like
> working in a Unix environment and need to work on Windows,
> often use the two together.
>
> However, you don't have to use the two together, and many don't.

Thanks for the explanation. Dare I ask where cygwin fits in? That's what
I typically use, and it is braindead simple (which, apparently, is what
I need).

>> 2) Stephan's mingw distribution doesn't include gcc. I'm wondering how
>> he expects things to work.
>
> Huh? When I extract http://nuwen.net/files/mingw/mingw-11.2.exe, I
> see a MinGW/bin/gcc.exe.

Oh man. I just followed Stephan's instructions here:

http://article.gmane.org/gmane.comp.lib.boost.devel/245604

That's clearly not enough. Is there any step-by-step instructions I can
follow to verify whether the fix is working or not? Sorry for the back
and forth, but I've managed to get myself pretty confused.

--
Eric Niebler
Boost.org
http://www.boost.org

[Nathan Ridge]

>> MinGW and MSYS are two different things.
>>
>> MinGW is a Windows port of gcc.
>>
>> MSYS is a Windows port of just enough of a Unix environment (shell,
>> coreutils, autotools and such) to build projects that use an autotools
>> (configure+make) build system on Windows.
>>
>> The only relation between the two is:
>> - MSYS, and the original (and still most commonly used) variant of
>> MinGW, are made by the same group of people (MinGW.org)
>> - People who port Unix programs to Windows, or who just like
>> working in a Unix environment and need to work on Windows,
>> often use the two together.
>>
>> However, you don't have to use the two together, and many don't.
>
> Thanks for the explanation. Dare I ask where cygwin fits in? That's what
> I typically use, and it is braindead simple (which, apparently, is what
> I need).

Cygwin provides a port of gcc AND a Unix environment in which you can
build autotools projects AND a complete POSIX API implementation so
that you can compile programs that make POSIX system calls like fork()
(and a package management system and a few other things including
the kitchen sink).

An important difference between MinGW and Cygwin is that the programs
produced by Cygwin need to be linked to a DLL which is GPL-licensed,
and which therefore requires that the entire program be GPL-licensed.
This is why many people who don't need the extra functionality provided
by Cygwin (the POSIX APIs), use MinGW instead.

>>> 2) Stephan's mingw distribution doesn't include gcc. I'm wondering how
>>> he expects things to work.
>>
>> Huh? When I extract http://nuwen.net/files/mingw/mingw-11.2.exe, I
>> see a MinGW/bin/gcc.exe.
>
> Oh man. I just followed Stephan's instructions here:
>
> http://article.gmane.org/gmane.comp.lib.boost.devel/245604
>
> That's clearly not enough. Is there any step-by-step instructions I can
> follow to verify whether the fix is working or not? Sorry for the back
> and forth, but I've managed to get myself pretty confused.

Those instructions seem to assume that you already have his MinGW
distro installed. It's very simple to install, just follow the "How to install"
section at http://nuwen.net/mingw.html.

Regards,
Nate

[Stephan T. Lavavej]

[Nathan Ridge]

> I have a very basic question: what is the difference between bootstrap.bat
> and bootstrap.sh in terms of what they do? Obviously one is designed to
> be run in cmd.exe and the other in a Unix shell (which on Windows can
> be provided by Cygwin or MSYS or something else), but does it matter
> which one I use?

They should behave identically.

STL

[Stephan T. Lavavej]

[niXman]
> The same error.

Thanks. I don't know why bootstrap.bat is exploding for you, but that
exonerates my changes.

Eric - this should unblock you from merging checkin 86460 to release.

[Eric Niebler]

> builtins.c:1879:39: error: 'FSCTL_GET_REPARSE_POINT' undeclared (first use
in this function)

> So it looks like something is still broken. Stephan?

This is a separate problem which must have appeared after 1.54.0, otherwise
I would have complained about it.

[Steven Watanabe]

> The problem is that MinGW's windows.h is only a
> subset of the real windows.h. This is part
> of the code used to handle symlinks for the
> git transition. I didn't test it on mingw.

If you can fix this for 1.55.0's release, that would be wonderful. A fix in
trunk would be almost as good, since I could backport it. Otherwise, I'll
have to figure out how to hack around this myself.

By the way, mingw-w64's maintainers are very responsive - if you need more
stuff from their headers, I'm sure they'll happily provide it.

[Eric Niebler]

> Why use the posix emulator? Why use mingw at all? I confess to be
> totally n00b about this stuff, but if you want to build boost using gcc
> on windows, it would seem to make sense to me to install mingw and then
> do things The Mingw Way, no?

Both bootstrap.bat and bootstrap.sh are valid approaches. Years ago, I used
to use the .bat, but I switched to the .sh because I have to build
everything else in MSYS.

> 1) There is a bootstrap.bat both at $BOOST_ROOT and and
> $BOOST_ROOT/tools/build/v2. They are different. Are we all taking about
> the same one? Which one should I be using (and why do we have two)?

I am familiar with the .bat in the root. I don't know what the other one is
doing.

> 2) Stephan's mingw distribution doesn't include gcc. I'm wondering how
> he expects things to work.

Why do you say that? Of course I have it.

C:\Temp>where gcc
C:\MinGW\bin\gcc.exe

C:\Temp>gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.8.1/lto
-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../src/configure --enable-languages=c,c++
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
--target=x86_64-w64-mingw32 --disable-multilib --prefix=/c/temp/gcc/dest
--with-sysroot=/c/temp/gcc/dest --disable-libstdcxx-pch --disable-lto
--disable-nls --disable-shared --disable-win32-registry
--enable-checking=release --with-tune=core-avx-i
Thread model: win32
gcc version 4.8.1 (GCC)

As my page explains, my distro does not modify your system, so gcc.exe will
not automatically appear in your Command Prompt's path. You must either run
set_distro_paths.bat to put the distro on *that* Command Prompt's path (it
will not affect other/future instances), or double-click
open_distro_window.bat to open a new Command Prompt with the distro on its
path.

If you've mangled your installation (*), simply delete the directory and run
the self-extracting archive again. This is why I love zips and hate
installers.

STL
* I once received a bug report from a user who claimed that
C:\MinGW\x86_64-w64-mingw32\include\sys wasn't in the right place. He had
accidentally drag-moved it in Windows Explorer.

[Stephan T. Lavavej]

[Eric Niebler]

> That's clearly not enough. Is there any step-by-step instructions I can
> follow to verify whether the fix is working or not? Sorry for the back
> and forth, but I've managed to get myself pretty confused.

[Nathan Ridge]

> Those instructions seem to assume that you already have his MinGW
> distro installed. It's very simple to install, just follow the "How to
install"
> section at http://nuwen.net/mingw.html.

Yep. Sorry, I wrote that for Vladimir without realizing that somebody else
who wasn't familiar with the whole MinGW/MSYS story might read it.

The MinGW instructions on my page, plus the MSYS instructions near the
bottom, plus the additional clarification in the mail you were looking at,
should be straightforward.

I suppose there's one more thing to mention - MSYS is always 32-bit (and it
need not match the bitness of MinGW). Ignore the fact that my MSYS zip is
versioned as 10.4 - that's simply the last time I had to update it.

STL

[Eric Niebler]

On 10/28/2013 7:47 PM, Stephan T. Lavavej wrote:
> [niXman]
>> The same error.
>
> Thanks. I don't know why bootstrap.bat is exploding for you, but that
> exonerates my changes.
>
> Eric - this should unblock you from merging checkin 86460 to release.

OK, I got this working. I installed Stephan's mingw-64, did
"bootstrap.bat gcc" followed by "b2 toolset=gcc pch=off
--without-context --without-coroutine" and the build started using gcc
from mingw. (I didn't let it run to completion.) As a curiosity, I'll
note that the project-root.jam created by "bootstrap.bat gcc" contains a
"using msvc ;" and not "using gcc ;", which seems wrong to me.

I also did "./bootstrap.sh --with-toolset=gcc" from an MSYS prompt
followed by the above b2 command, and that also seemed to work.

Finally, I'll note that "./bootstrap.sh --with-toolset=mingw" does *not*
work. The subsequent ./b2 invocation cannot find mingw.jam. It's not
clear to me at this point when one should specify "mingw" as the
toolset, if ever.

I'm satisfied that Stephan's patch works. I don't know what problem
niXman is having, but we've ruled out Stephan's patch as the culprit.
I'll send a separate message asking for permission to merge to release.

--
Eric Niebler
Boost.org
http://www.boost.org

[niXman]

Eric Niebler 2013-10-29 11:33:

> OK, I got this working. I installed Stephan's mingw-64, did
> "bootstrap.bat gcc" followed by "b2 toolset=gcc pch=off
> --without-context --without-coroutine" and the build started using gcc
> from mingw.

What revision are you using? Current trunk?

--
Regards, niXman
___________________________________________________
Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:
http://sourceforge.net/projects/mingw-w64/
___________________________________________________
Another online IDE: http://liveworkspace.org/

[Steven Watanabe]

AMDG

On 10/28/2013 07:26 PM, Stephan T. Lavavej wrote:
> [Nathan Ridge]
>> I have a very basic question: what is the difference between bootstrap.bat
>> and bootstrap.sh in terms of what they do? Obviously one is designed to
>> be run in cmd.exe and the other in a Unix shell (which on Windows can
>> be provided by Cygwin or MSYS or something else), but does it matter
>> which one I use?
>
> They should behave identically.
>

They're mostly the same. bootstrap.sh is
a little smarter than booststrap.bat.

In Christ,
Steven Watanabe

[Steven Watanabe]

AMDG

On 10/29/2013 12:33 AM, Eric Niebler wrote:
> On 10/28/2013 7:47 PM, Stephan T. Lavavej wrote:
>> [niXman]
>>> The same error.
>>
>> Thanks. I don't know why bootstrap.bat is exploding for you, but that
>> exonerates my changes.
>>
>> Eric - this should unblock you from merging checkin 86460 to release.
>
> OK, I got this working. I installed Stephan's mingw-64, did
> "bootstrap.bat gcc" followed by "b2 toolset=gcc pch=off
> --without-context --without-coroutine" and the build started using gcc
> from mingw. (I didn't let it run to completion.) As a curiosity, I'll
> note that the project-root.jam created by "bootstrap.bat gcc" contains a
> "using msvc ;" and not "using gcc ;", which seems wrong to me.
>

bootstrap.bat sets msvc unconditionally.
The language for batch scripts is really
horrible, so working this out correctly
is likely to be very painful.

> I also did "./bootstrap.sh --with-toolset=gcc" from an MSYS prompt
> followed by the above b2 command, and that also seemed to work.
>
> Finally, I'll note that "./bootstrap.sh --with-toolset=mingw" does *not*
> work. The subsequent ./b2 invocation cannot find mingw.jam. It's not
> clear to me at this point when one should specify "mingw" as the
> toolset, if ever.
>
> I'm satisfied that Stephan's patch works. I don't know what problem
> niXman is having, but we've ruled out Stephan's patch as the culprit.
> I'll send a separate message asking for permission to merge to release.
>

In Christ,
Steven Watanabe

[Eric Niebler]

On 10/29/2013 9:55 AM, Steven Watanabe wrote:
>> As a curiosity, I'll
>> note that the project-root.jam created by "bootstrap.bat gcc" contains a
>> "using msvc ;" and not "using gcc ;", which seems wrong to me.
>
> bootstrap.bat sets msvc unconditionally.
> The language for batch scripts is really
> horrible, so working this out correctly
> is likely to be very painful.

It is a horrible language that I know quite well. If you write the
pseudo-code, I can translate it into command script for you.

--
Eric Niebler
Boost.org
http://www.boost.org

[Stephan T. Lavavej]

[Eric Niebler]

> I also did "./bootstrap.sh --with-toolset=gcc" from an MSYS prompt

> followed by the above b2 command ["b2 toolset=gcc pch=off
> --without-context --without-coroutine"], and that also seemed to work.

*Very* interesting - I wasn't aware that this could be done with
command-line arguments instead of my hacktrocity patch. (Maybe I never tried
"gcc" on both sides, or I did but something changed - the last time I
checked was years ago.)

Thanks,
STL

[Steven Watanabe]

AMDG

On 10/29/2013 10:08 AM, Eric Niebler wrote:
> On 10/29/2013 9:55 AM, Steven Watanabe wrote:
>>> As a curiosity, I'll
>>> note that the project-root.jam created by "bootstrap.bat gcc" contains a
>>> "using msvc ;" and not "using gcc ;", which seems wrong to me.
>>
>> bootstrap.bat sets msvc unconditionally.
>> The language for batch scripts is really
>> horrible, so working this out correctly
>> is likely to be very painful.
>
> It is a horrible language that I know quite well. If you write the
> pseudo-code, I can translate it into command script for you.
>

In tools/v2/build/engine/build.bat:

if --guess-toolset in $argv
call :Guess_Toolset
return $BOOST_JAM_TOOLSET

Also, make sure that local variables don't escape.
I don't know how to pass the return value through setlocal.

(I just noticed this in bootstrap.bat:
REM Ideally, we should obtain the toolset that build.bat has
REM guessed. However, it uses setlocal at the start and does not
REM export BOOST_JAM_TOOLSET, and I don't know how to do that
REM properly. Default to msvc for now.)

in bootstrap.bat:

TOOLSET = find argument --with-toolset=xxx
if not $TOOLSET
set TOOLSET=`tools/build/v2/engine/build.bat --guess-toolset`

In Christ,
Steven Watanabe

[Marcel Raad]

Stephan T. Lavavej <stl <at> nuwen.net> writes:



> P.S. x86 is dead! :->

Please tell this to Intel who refuse to offer 64-bit VGA drivers for their
Atom 2800...

[Eric Niebler]

On 10/29/2013 10:36 AM, Steven Watanabe wrote:
> On 10/29/2013 10:08 AM, Eric Niebler wrote:
>> On 10/29/2013 9:55 AM, Steven Watanabe wrote:
>>>> As a curiosity, I'll
>>>> note that the project-root.jam created by "bootstrap.bat gcc" contains a
>>>> "using msvc ;" and not "using gcc ;", which seems wrong to me.
>>>
>>> bootstrap.bat sets msvc unconditionally.
>>> The language for batch scripts is really
>>> horrible, so working this out correctly
>>> is likely to be very painful.
>>
>> It is a horrible language that I know quite well. If you write the
>> pseudo-code, I can translate it into command script for you.
>
> In tools/v2/build/engine/build.bat:
>
> if --guess-toolset in $argv
> call :Guess_Toolset
> return $BOOST_JAM_TOOLSET
>
> Also, make sure that local variables don't escape.
> I don't know how to pass the return value through setlocal.

The hackish way to do this is to write the "return value" into a file,
and then read it back in.

> (I just noticed this in bootstrap.bat:
> REM Ideally, we should obtain the toolset that build.bat has
> REM guessed. However, it uses setlocal at the start and does not
> REM export BOOST_JAM_TOOLSET, and I don't know how to do that
> REM properly. Default to msvc for now.)
>
> in bootstrap.bat:
>
> TOOLSET = find argument --with-toolset=xxx

Doable.

> if not $TOOLSET
> set TOOLSET=`tools/build/v2/engine/build.bat --guess-toolset`

This doesn't seem right. build.bat takes a toolset as an optional
argument. If the user specified --with-toolset=xxx to bootstrap.bat,
then shouldn't xxx get passed as the toolset argument to build.bat?

--
Eric Niebler
Boost.org
http://www.boost.org

[Steven Watanabe]

AMDG

On 10/30/2013 01:16 PM, Eric Niebler wrote:
>
>> if not $TOOLSET
>> set TOOLSET=`tools/build/v2/engine/build.bat --guess-toolset`
>
> This doesn't seem right. build.bat takes a toolset as an optional
> argument. If the user specified --with-toolset=xxx to bootstrap.bat,
> then shouldn't xxx get passed as the toolset argument to build.bat?
>

I'm mirroring the logic in bootstrap.sh. This doesn't
actually build anything, it just asks build.bat to
figure out what toolset it would use. If the user
specified a toolset, we already know.

In Christ,
Steven Watanabe