On 10/20/2013 11:58 PM, Dave Abrahams wrote:

on Sat Oct 19 2013, "Stephan T. Lavavej" 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.

on Sun Oct 20 2013, Rene Rivera 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*.

On Sun, Oct 20, 2013 at 10:58 PM, Dave Abrahams wrote:

...

on Sat Oct 19 2013, "Stephan T. Lavavej" 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

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

--

-- Dave Abrahams

on Sun Oct 20 2013, Vladimir Prus wrote:

On 21.10.2013 07:58, Dave Abrahams wrote:

...

on Sat Oct 19 2013, "Stephan T. Lavavej" 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

[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. STL

On Mon, Oct 21, 2013 at 12:32 PM, Vladimir Prus wrote:

On 21.10.2013 21:03, Stephan T. Lavavej wrote:

...

[STL]

...

http://lists.boost.org/boost-**build/2013/10/27025.phphttp://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.patchhttp://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

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 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? -- 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/

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 !

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.

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 !

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.

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. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

[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

On Sat, Oct 26, 2013 at 4:39 AM, Stephan T. Lavavej wrote: I do not have commit access...

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

[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

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 libboost_context.a(clean) for lack of asm/make_x86_64_sysv_elf_gas.o... ...skipped libboost_context.a for lack of asm/make_x86_64_sysv_elf_gas.o... ...skipped

libboost_context.a for lack of 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’: ./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::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’: ./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::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 libboost_log.a(clean) for lack of date_time_format_parser.o... ...skipped libboost_log.a for lack of date_time_format_parser.o... ...skipped

libboost_log.a for lack of 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 писал 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/

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? -- 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/

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

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?

bootstrap.bat works fine with MinGW for boost 1.51,1.52,1.53,1.54. But not for current trunk. Ideas? -- 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/

[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

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

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

...

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

...

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

[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.

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/

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

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

[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

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).as...) 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/

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

Stephan T. Lavavej writes:

P.S. x86 is dead! :->

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

[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

AMDG On 10/21/2013 10:32 AM, Vladimir Prus wrote:

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?

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