Boost C++ Libraries: Ticket #4839: boost_thread will not build with MinGW-w64 and bjam on Windows 7

attachment set

fatman@… — Thu, 11 Nov 2010 11:04:18 GMT

attachment → thread.log.txt

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

fatman@… — Thu, 11 Nov 2010 14:33:16 GMT

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 — Tue, 16 Nov 2010 20:53:50 GMT

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

cc set

viboes — Tue, 16 Nov 2010 20:56:23 GMT

cc viboes added

fatman@… — Wed, 17 Nov 2010 09:37:35 GMT

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

attachment set

fatman@… — Wed, 17 Nov 2010 21:56:31 GMT

attachment → thread.log.d2.txt

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

fatman@… — Wed, 17 Nov 2010 22:01:46 GMT

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 — Sat, 27 Nov 2010 15:12:48 GMT

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?

cc changed

Tue, 30 Nov 2010 15:12:25 GMT

cc sebastian.held@… added

fatman@… — Thu, 23 Dec 2010 13:16:19 GMT

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

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

fatman@… — Thu, 23 Dec 2010 22:39:50 GMT

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.

attachment set

fatman@… — Thu, 23 Dec 2010 22:41:49 GMT

attachment → thread.log.2.txt

New output from altered environment

Tue, 04 Jan 2011 20:43:47 GMT

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

cc changed

Tue, 04 Jan 2011 22:20:15 GMT

cc jim@… added

fatman@… — Wed, 05 Jan 2011 14:49:15 GMT

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.

version, milestone changed

Fri, 07 Jan 2011 16:36:45 GMT

version Boost 1.44.0 → Boost Development Trunk
milestone To Be Determined → Boost 1.46.0

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@… — Wed, 19 Jan 2011 22:54:18 GMT

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

severity changed

fatman@… — Wed, 19 Jan 2011 23:07:10 GMT

severity Showstopper → Problem

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.

Thu, 20 Jan 2011 17:34:10 GMT

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.

severity changed

fatman@… — Thu, 20 Jan 2011 21:29:44 GMT

severity Problem → Showstopper

Good points. Back to "showstopper" then.

mikko.vainio@… — Mon, 06 Jun 2011 09:59:38 GMT

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@… — Mon, 04 Jul 2011 15:58:45 GMT

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

fatman@… — Mon, 04 Jul 2011 19:59:03 GMT

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 — Sun, 11 Dec 2011 09:27:13 GMT

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.

keywords set

viboes — Sun, 11 Dec 2011 16:39:25 GMT

keywords 64 interlocked added

jim@… — Mon, 12 Dec 2011 01:10:27 GMT

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?

status changed; resolution set; milestone deleted

viboes — Tue, 03 Jan 2012 16:48:10 GMT

status new → closed
resolution → worksforme
milestone Boost 1.46.0

Closed as no one disagree :)

kalast@… — Sat, 21 Apr 2012 17:39:55 GMT

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@… — Sat, 21 Apr 2012 17:57:43 GMT

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