boost_thread will not build with MinGW-w64 and bjam on Windows 7

[fatman@…]

OS:
Windows 7 Ultimate (64-bit)

Compiler:
MinGW-w64

> g++ --version[[BR]]
g++ (GCC) 4.5.2 20101015 (prerelease)

Command line:

bjam.exe toolset=gcc stage --build-type=complete --with-thread >thread.log.txt

(I have used bootstrap.bat to build a native version of bjam.exe.)

Output: please see attached thread.log.txt.

To summarise, boost_thread seems to be the only binary Boost library which won't build in my MinGW-w64 build environment. Running without --with-thread results in 250-odd libboost*.a files in my stage/lib directory (as expected) but without boost_thread.

Please see also bug 4804. This is similar but not quite the same bug. His bug occurred while /linking against/ boost_thread; mine occurs while /building/ boost_thread.

Thanks for reading.

[fatman@…]

Output from bjam with stage and --with-thread on MinGW-w64

[fatman@…]

Line 45 of the output:

./boost/thread/win32/interlocked_read.hpp:71:13: error: cast from 'void*' to 'long int' loses precision

suggests we're casting a pointer to a 32-bit integer. We can get away with that in 32 bits, but on a 64-bit system? No kidding it loses precision, we've just thrown away half the pointer. I'm guessing that's not the intended effect?

[viboes]

Hi,

it will be useful if you can provide the result of bjam -d2, so we can see the compiler command line. Also useful could be the output of the preprocessing (replace -c in the command line by -E).

Best, Vicente

[fatman@…]

Thanks Vicente. I'll attach the outputs as soon as they're ready.

[fatman@…]

Same command line but with -d2 at the end, before the redirect

[fatman@…]

Ok, I've run the same command with -d2 at the end:

bjam.exe toolset=gcc stage --build-type=complete --with-thread -d2 >thread.log.d2.txt

When I add -E to the command line, I get "Invalid option: -E". Are you thinking about a different command?

[viboes]

Replying to fatman@…:

Ok, I've run the same command with -d2 at the end:

bjam.exe toolset=gcc stage --build-type=complete --with-thread -d2 >thread.log.d2.txt

When I add -E to the command line, I get "Invalid option: -E". Are you thinking about a different command?

Could you try

    "g++"  -ftemplate-depth-128 -O0 -fno-inline -Wall -g -mthreads -Wno-long-long -DBOOST_ALL_NO_LIB=1 -DBOOST_THREAD_BUILD_DLL=1  -I"." -E -o "bin.v2\libs\thread\build\gcc-mingw-4.5.2\debug\threading-multi\win32\thread.o" "libs\thread\src\win32\thread.cpp"

and check where the first error occurs?

[fatman@…]

Apologies for the delay in replying. I have been away.

I will try your suggestion as soon as I get home from work.

[fatman@…]

My build environment has changed slightly. Now:

> g++ --version
g++ (GCC) 4.4.5 20101001 (release) [svn/rev.164871 - mingw-w64/oz]

and I'm using Boost 1.40, and I've generated some new output with the command:

bjam.exe toolset=gcc stage --build-type=complete --with-thread >thread.log.txt

which I will attach.

Vicente, I've altered your command slightly to reflect the change of compiler version.

g++ -ftemplate-depth-128 -O0 -fno-inline -Wall -g -mthreads -Wno-long-long DBOOST_ALL_NO_LIB=1 -DBOOST_THREAD_BUILD_DLL=1 -I"." -E -o "bin.v2\libs\thread\build\gcc-mingw-4.4.5\debug\threading-multi\win32\thread.o" "libs\thread\src\win32\thread.cpp"

It returns with no output. boost_thread still won't build, though.

[fatman@…]

New output from altered environment

[Jim Bell <jim@…>]

As a point of reference, boost.thread builds for my MinGW-64 boost regression test. See the trunk regression matrix, column "Win7-x64 jc-bell.com" (current as of 2011-04-01).

Also see patches here: ​http://lists.boost.org/boost-users/2010/12/65214.php

[fatman@…]

Thanks Jim, most interesting, although I find the huge tables of test results a bit overwhelming. Some bedtime reading there for sure.

In reference to your comment in the patches thread that bootstrap.bat needs hacking to work with gcc, I found I was able to build a native bjam.exe by running tools/jam/build.bat (path?) myself, and IIRC I just had to set the toolchain to gcc in build.bat. Hope that's of use to you.

[Jim Bell <jim@…>]

I'm updating the milestone & version on this so that it gets picked up for the 1.46 release. Sadly, though it's marked "showstopper," being marked "Milestone: TBD" and/or "Version: 1.44", it gets missed by the release managers. (Follow the thread back from <​http://lists.boost.org/Archives/boost/2010/10/172431.php>.)

[fatman@…]

Ah. Hm. I marked the bug as "showstopper" because I am unable to use boost_thread if it won't compile. Was that wrong?

[fatman@…]

This is a useful page. -> ​https://svn.boost.org/trac/boost/wiki/TicketWorkflow

Now I can see I set the bug severity way too high. I'll reset it to "problem" since I have no idea if it's a regression or not.

[Jim Bell <jim@…>]

My ​regression test promotes it to regression, IMO, once my regression gets running on a regular schedule.

And I don't think showstopper is way too high myself. I think 1.46 is going to ship without it, but if I can get my regression-testing act together on this, I say we promote it to showstopper then.

This is an important platform and compiler.

[fatman@…]

Good points. Back to "showstopper" then.

[mikko.vainio@…]

I'm seeing this bug in the release branch but not in trunk r72431. Will the changes in trunk be merged to release for 1.47.0?

[fatman@…]

Hmm. Well, I hope they fix this some day - guess I'll have to abandon Boost for now. :(

[fatman@…]

I had a last-ditch poke around in Boost's internals and it looks like I found a workaround. :D

Thanks to the OP on bug 4804 for the clue.

Applying this patch to boost/detail/interlocked.hpp allows Boost.Thread to build (hopefully not breaking something else):

9a10,11
> #define BOOST_USE_WINDOWS_H 1
>

Obviously this is not a proper fix; I'm guessing it breaks Boost.Thread on other platforms than Windows. It can be applied to Windows x64 build environments individually.

Glad I don't have to ditch Boost after all. :)

[viboes]

Replying to fatman@…:

I had a last-ditch poke around in Boost's internals and it looks like I found a workaround. :D

Thanks to the OP on bug 4804 for the clue.

Applying this patch to boost/detail/interlocked.hpp allows Boost.Thread to build (hopefully not breaking something else):

9a10,11
> #define BOOST_USE_WINDOWS_H 1
>

Obviously this is not a proper fix; I'm guessing it breaks Boost.Thread on other platforms than Windows. It can be applied to Windows x64 build environments individually.

Glad I don't have to ditch Boost after all. :)

I don't know if that helps you, you can define BOOST_USE_WINDOWS_H directly on the command line.

[jim@…]

Note that I've been running the boost regression tests on MinGW-w64, Windows 7 x64 for the last couple months, and thread builds fine (passes its regressions), for gcc 4.7, 4.6, 4.5 and 4.4 (besides the tss issue). See http://www.boost.org/development/tests/release/developer/thread.html. So I'm pretty sure these issues are cleared up. Anyone disagree?

[viboes]

Closed as no one disagree :)

[kalast@…]

Hi, using this ​https://sourceforge.net/projects/mingwbuilds/files/windows-host/4.7.0/ build results in the same errors for thread unfortunately. Will test latest release to see if it's fixed.

[kalast@…]

Hello again, looks like 1.49 works correctly, sorry for the noise.