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-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?

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