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-10 14:35:24
On Tue, Jul 28, 2015 at 9:49 AM, Vladimir Prus <vladimir.prus_at_[hidden]> wrote:
>
> Hi Tom,
>
> On 28-Jul-15 3:44 AM, Tom Kent wrote:
>
>> Looking at the boost-build code, this batch file is created in
>> build/src/tools/msvc.jam:744. This file will create the temp file in
>> question by grabbing the output of a run of the visual studio environment
>> setup routine (i.e. C:\Program Files (x86)\Microsoft Visual Studio
>> 14.0\vc\vcvarsall.bat amd64). However, for the msvc-14.0 /
>> address-model=64
>> case, it seems that it is combining the 32 bit and 64 bit variables into
>> one causing this issue (and other variables that shouldn't be set by the
>> amd64 run, such as FrameworkVersion32 and FrameworkVersion64...just
>> running
>> the above command only sets FrameworkVersion64).
>>
>> Is it possible that build is running the 32 bit variable file, then
>> running
>> the 64 bit instance?
>
>
> local original-vars = [ SPLIT_BY_CHARACTERS [ SHELL set ] : "\n"
> ] ;
> local new-vars = [ SPLIT_BY_CHARACTERS [ SHELL "$(setup-script)
> $(setup-options)>nul && set" ] : "\n" ] ;
> local diff-vars = [ set.difference $(new-vars) :
> $(original-vars) ] ;
>
> So we should be capturing the changes that the particular setup script does
> to environment; it's not obvious
> why this would start to fail with VS 14 - adding
>
> ECHO $(diff-vars) ;
>
> after the above lines might be illuminating. I'm installing VS 14 now, but
> it might take a day till
> I get to debug.
I have tried to add this echo and indeed it outputs the broken Path
already. Also, I tried to print %PATH% from the console (VS2015 x86
x64 Cross Tools Command Prompt) and it also has the %DevEnvDir% path
first there.
I inspected the vcvarsx86_amd64.bat script which sets up the
environment and I can see that in line 62 it indeed inserts
%DevEnvDir% before the paths to the compilers, so we have our culprit.
The question is what do we do about it?