On Tue, Aug 11, 2015 at 3:35 AM, Gavin Lambert
Mere moments ago, quoth I:
Ok, examining msvc.jam I think I've found the issue. It defaults to "x86_amd64" (cross compiler), and then swaps this to "amd64" (native compiler) if the environment variable PROCESSOR_ARCHITECTURE is set to AMD64.
However this will only be the case if the process executing the jam file is also 64-bit. A 32-bit process running under WOW64 will see "x86" for that environment variable, just like it would on 32-bit Windows.
So, either Boost.Build itself needs to be a 64-bit process, or it needs to be more clever at detecting a 64-bit architecture even as a 32-bit process. The simplest way of doing the latter is to read PROCESSOR_ARCHITEW6432, which will be unset for native 32 or 64-bit and set to AMD64 on 32-bit WOW64. (ie. the jamfile should assume native 64-bit if either of PROCESSOR_ARCHITECTURE or PROCESSOR_ARCHITEW6432 are set to AMD64.)
PR for the latter workaround: https://github.com/boostorg/build/pull/87
Thanks Gavin. I have tried this change and it fixes the problem (both in develop and RC2), so we can use it at least as a workaround for 1.59. I can understand the current Boost.Build behavior though. Normally you build binaries for the same architecture the build tool is built for, which is 32-bit x86 in case of 32-bit bjam. When you build for another architecture, like amd64, this is a cross build, and it is logical to use a cross-compiler for that. This approach also makes it possible to build 64-bit binaries on a 32-bit machine, although in case of x86 I doubt this is a highly demanded feature. I wonder if we should be building a 64-bit bjam on a 64-bit Windows by default though. It's not a change for 1.59 but still worth considering for future releases.