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

Subject: Re: [Boost-build] [boost] [build] Problems with VC14 and MSPDB140.DLL (was: [testing][teeks] MSVC-14 errors about MSPDB140.DLL)
From: Tom Kent (lists_at_[hidden])
Date: 2015-07-27 20:44:31

On Sun, Jul 26, 2015 at 3:35 PM, Tom Kent <lists_at_[hidden]> wrote:

>
> On Sun, Jul 26, 2015 at 8:10 AM, Andrey Semashev <
> andrey.semashev_at_[hidden]> wrote:
>
>> On Sat, May 23, 2015 at 4:40 PM, Hartmut Kaiser
>> <hartmut.kaiser_at_[hidden]> wrote:
>> >
>> >> All tests for Boost.Log (and I suspect any other built libraries) on
>> MSVC-
>> >> 14
>> >> are failing because of this error:
>> >>
>> >> LINK : fatal error LNK1101: incorrect MSPDB140.DLL version; recheck
>> >> installation of this product
>> >
>> > My workaround was to edit the 'Path' env variable in one of the temp
>> files
>> > generated by bjam (b2_msvc_14.0_vcvarsall_amd64.cmd in your temp
>> directory)
>> > not to point to the x64 cross compiler, but to the native one. For me
>> this
>> > involved changing
>> >
>> > C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64_x86
>> >
>> > To
>> >
>> > C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64
>>
>> I encountered the same problem with VC14 RTM on my VM. This was a
>> clean install of VC14 RTM, there were no CTPs or RCs installed on this
>> machine. I removed the b2_msvc_14.0_vcvarsall*.cmd scripts and ran b2
>> with address-model=64 to build my tests so that these scripts are
>> re-created from scratch, so it looks like there is a problem with how
>> these scripts are generated by b2.
>>
>> I found 3 instances of mspdb140.dll on my system in these locations:
>>
>> C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE
>> C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin
>> C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64
>>
>> The last two are for 32 and 64-bit native compilers. The first one, I
>> assume, is for use by IDE. The problem is that the first path is
>> listed in b2_msvc_14.0_vcvarsall_x86_amd64.cmd in the "SET Path=..."
>> line prior to the compiler-specific paths. Removing it from the Path
>> solved the problem.
>>
>> Could Boost.Build be adjusted so that the cmd files are generated
>> correctly in the first place?
>>
>
> Yes! I've been struggling with this all weekend trying to figure out what
> was going wrong. I've don multiple re-installs of my VM thinking that I
> might have gotten something corrupted. Your results seem to match what I
> was seeing exactly.
>

After experimenting a bit more, I've been able to exactly re-produce what
Andrey saw. I would consider this something that would be a blocking bug
for the 1.59.0 release, as it prevents any user from successfully building
64-bit binaries of boost with msvc-14.0....at least without the user going
into their temp directory and editing a file that was created by boost
build.

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?

Tom