# 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 15:22:11

On Mon, Aug 10, 2015 at 9:35 PM, Andrey Semashev
<andrey.semashev_at_[hidden]> wrote:
> 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 /
>>> 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?

I created a Connect ticket about it: