Re: [boost] [build] Problems with VC14 and MSPDB140.DLL (was: [testing][teeks] MSVC-14 errors about MSPDB140.DLL)

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 03:34:50

On 11/08/2015 19:11, Andrey Semashev wrote:
>> 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 environment.)
>>
>> 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. :)
>
> I'm not the author of that code but I suspect the reason for that is
> that the amd64_x86 cross-compiler was not shipped until VS2015; there
> was only the native x86 compiler. I think it is safe to keep using it
> (the x86 compiler) since we know every 64-bit Windows is able to run
> 32-bit programs. The other way around is not true though - not every
> Windows that manifests itself as 32-bit is able to run 64-bit
> programs.

I agree that it's probably safe to continue using the native x86 
compiler -- although note as above that it *is* possible (though very 
unlikely) to encounter an x64 system that can't run x86.

Also the amd64_x86 compiler does appear to be present in VS2013 (not 
sure if it was in RTM or one of the updates, but it is absent in VS2012).

It might be interesting to do some performance tests of x86 vs. 
amd64_x86 on some large libraries, however -- it's possible one might be 
noticeably better than the other, though I'm not sure which way to bet.