Subject: Re: [boost] [build] Problems with VC14 and MSPDB140.DLL (was: [testing][teeks] MSVC-14 errors about MSPDB140.DLL)
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-08-11 01:47:20
On 11/08/2015 16:55, Andrey Semashev wrote:
> 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.
On Linux, yes; things are a bit murkier on Windows.
On Linux it's common that installing the 64-bit variant will result in
almost all installed software also being 64-bit. As a result it's
reasonably safe (though not foolproof) to assume that whatever is
running is the native architecture.
On Windows it's still common for almost all software installed to be
32-bit regardless of whether the OS itself is 32-bit or 64-bit, and the
OS is quite good at pretending the world is 32-bit when running a 32-bit
app, for backwards compatibility reasons.
The Visual Studio IDE itself is 32-bit, regardless of whether it runs
the x86 or the amd64 native compilers, or some cross-compiler.
Generally Windows software only gets a 64-bit flavour if it needs to
integrate with something in the OS (eg. shell extensions, drivers) or if
it's expecting high memory usage.
> 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.
That would be another way to solve it, yes. Although then the question
would be whether it should use the native x86 compiler or the amd64_x86
cross-compiler. (It is actually possible in some Windows versions to
remove the ability to run 32-bit code, although I would be quite
surprised if anyone actually does that, especially in a development
Note that currently a 64-bit bjam *won't* use the cross-compiler; I
think it just operates on a "by default we're running x86" assumption
rather than trying to follow the native architecture like you suggested
above. Comments near the code I patched seem to support this. :)