Boost logo

Boost :

Subject: Re: [boost] [build] Problems with VC14 and MSPDB140.DLL (was: [testing][teeks] MSVC-14 errors about MSPDB140.DLL)
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-08-11 00:55:43

On Tue, Aug 11, 2015 at 3:35 AM, Gavin Lambert <gavinl_at_[hidden]> wrote:
> 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
>> set to AMD64.)
> PR for the latter workaround:

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

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at