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

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Andrey Semashev-2
On Sat, May 23, 2015 at 4:40 PM, Hartmut Kaiser
<[hidden email]> 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?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Tom Kent
On Sun, Jul 26, 2015 at 8:10 AM, Andrey Semashev <[hidden email]>
wrote:

> On Sat, May 23, 2015 at 4:40 PM, Hartmut Kaiser
> <[hidden email]> 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.

Tom

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

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

>
> On Sun, Jul 26, 2015 at 8:10 AM, Andrey Semashev <
> [hidden email]> wrote:
>
>> On Sat, May 23, 2015 at 4:40 PM, Hartmut Kaiser
>> <[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Vladimir Prus-4

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.

- Volodya



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Tom Kent
On Tue, Jul 28, 2015 at 1:49 AM, Vladimir Prus <[hidden email]>
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.
>
> - Volodya
>
>
Does anyone know if any progress has been made on this?  I think that the
1.59 release is just around the corner, and I would consider this a
show-stopper as a user can't do a build for msvc-14.0 with address-model=64.

Tom

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Andrey Semashev-2
On 07.08.2015 18:37, Tom Kent wrote:

> On Tue, Jul 28, 2015 at 1:49 AM, Vladimir Prus <[hidden email]>
> 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.
>>
>> - Volodya
>>
>>
> Does anyone know if any progress has been made on this?  I think that the
> 1.59 release is just around the corner, and I would consider this a
> show-stopper as a user can't do a build for msvc-14.0 with address-model=64.

+1, I agree with the 'show-stopper' here.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

John Maddock-2
What are the steps to reproduce this?  64-bit msvc-14 builds seem to be
OK for me,

John.


On 07/08/2015 16:56, Andrey Semashev wrote:

> On 07.08.2015 18:37, Tom Kent wrote:
>> On Tue, Jul 28, 2015 at 1:49 AM, Vladimir Prus <[hidden email]>
>> 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.
>>>
>>> - Volodya
>>>
>>>
>> Does anyone know if any progress has been made on this?  I think that
>> the
>> 1.59 release is just around the corner, and I would consider this a
>> show-stopper as a user can't do a build for msvc-14.0 with
>> address-model=64.
>
> +1, I agree with the 'show-stopper' here.
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Andrey Semashev-2
On 07.08.2015 19:09, John Maddock wrote:
> What are the steps to reproduce this?  64-bit msvc-14 builds seem to be
> OK for me,

I described my steps at the beginning of the thread:

http://boost.2283326.n4.nabble.com/build-Problems-with-VC14-and-MSPDB140-DLL-was-testing-teeks-MSVC-14-errors-about-MSPDB140-DLL-td4678359.html

Did you remove the b2_msvc_14.0_vcvarsall* files in your temp directory?

> On 07/08/2015 16:56, Andrey Semashev wrote:
>> On 07.08.2015 18:37, Tom Kent wrote:
>>> On Tue, Jul 28, 2015 at 1:49 AM, Vladimir Prus <[hidden email]>
>>> 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.
>>>>
>>>> - Volodya
>>>>
>>>>
>>> Does anyone know if any progress has been made on this?  I think that
>>> the
>>> 1.59 release is just around the corner, and I would consider this a
>>> show-stopper as a user can't do a build for msvc-14.0 with
>>> address-model=64.
>>
>> +1, I agree with the 'show-stopper' here.
>>
>>
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

John Maddock-2


On 07/08/2015 17:24, Andrey Semashev wrote:

> On 07.08.2015 19:09, John Maddock wrote:
>> What are the steps to reproduce this? 64-bit msvc-14 builds seem to be
>> OK for me,
>
> I described my steps at the beginning of the thread:
>
> http://boost.2283326.n4.nabble.com/build-Problems-with-VC14-and-MSPDB140-DLL-was-testing-teeks-MSVC-14-errors-about-MSPDB140-DLL-td4678359.html 
>
>
> Did you remove the b2_msvc_14.0_vcvarsall* files in your temp directory?
>

Got it, can confirm it's an issue when building with 32-bit bjam (which
uses the cross compiler), if you build with 64-bit bjam then it uses the
native 64-bit compiler, and everything is OK.

IMO we should find a way to fix this.  John.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Andrey Semashev-2
On 07.08.2015 21:21, John Maddock wrote:

>
>
> On 07/08/2015 17:24, Andrey Semashev wrote:
>> On 07.08.2015 19:09, John Maddock wrote:
>>> What are the steps to reproduce this? 64-bit msvc-14 builds seem to be
>>> OK for me,
>>
>> I described my steps at the beginning of the thread:
>>
>> http://boost.2283326.n4.nabble.com/build-Problems-with-VC14-and-MSPDB140-DLL-was-testing-teeks-MSVC-14-errors-about-MSPDB140-DLL-td4678359.html
>>
>>
>> Did you remove the b2_msvc_14.0_vcvarsall* files in your temp directory?
>>
>
> Got it, can confirm it's an issue when building with 32-bit bjam (which
> uses the cross compiler), if you build with 64-bit bjam then it uses the
> native 64-bit compiler, and everything is OK.

I thought there's only one way to build bjam - by running
tools/build/src/engine/build.bat. That's how I've always been building
it anyway, and it always produced a 32-bit binary. How do you build a
64-bit bjam?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Tom Kent
On Fri, Aug 7, 2015 at 5:21 PM, Andrey Semashev <[hidden email]>
wrote:

> On 07.08.2015 21:21, John Maddock wrote:
>
>>
>>
>> On 07/08/2015 17:24, Andrey Semashev wrote:
>>
>>> On 07.08.2015 19:09, John Maddock wrote:
>>>
>>>> What are the steps to reproduce this? 64-bit msvc-14 builds seem to be
>>>> OK for me,
>>>>
>>>
>>> I described my steps at the beginning of the thread:
>>>
>>>
>>> http://boost.2283326.n4.nabble.com/build-Problems-with-VC14-and-MSPDB140-DLL-was-testing-teeks-MSVC-14-errors-about-MSPDB140-DLL-td4678359.html
>>>
>>>
>>> Did you remove the b2_msvc_14.0_vcvarsall* files in your temp directory?
>>>
>>>
>> Got it, can confirm it's an issue when building with 32-bit bjam (which
>> uses the cross compiler), if you build with 64-bit bjam then it uses the
>> native 64-bit compiler, and everything is OK.
>>
>
> I thought there's only one way to build bjam - by running
> tools/build/src/engine/build.bat. That's how I've always been building it
> anyway, and it always produced a 32-bit binary. How do you build a 64-bit
> bjam?
>
>
This problem will occur (with msvc-14.0) when using the bootstrap.bat file
specified in the getting started directions.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Edward Diener-3
On 8/7/2015 9:26 PM, Tom Kent wrote:

> On Fri, Aug 7, 2015 at 5:21 PM, Andrey Semashev <[hidden email]>
> wrote:
>
>> On 07.08.2015 21:21, John Maddock wrote:
>>
>>>
>>>
>>> On 07/08/2015 17:24, Andrey Semashev wrote:
>>>
>>>> On 07.08.2015 19:09, John Maddock wrote:
>>>>
>>>>> What are the steps to reproduce this? 64-bit msvc-14 builds seem to be
>>>>> OK for me,
>>>>>
>>>>
>>>> I described my steps at the beginning of the thread:
>>>>
>>>>
>>>> http://boost.2283326.n4.nabble.com/build-Problems-with-VC14-and-MSPDB140-DLL-was-testing-teeks-MSVC-14-errors-about-MSPDB140-DLL-td4678359.html
>>>>
>>>>
>>>> Did you remove the b2_msvc_14.0_vcvarsall* files in your temp directory?
>>>>
>>>>
>>> Got it, can confirm it's an issue when building with 32-bit bjam (which
>>> uses the cross compiler), if you build with 64-bit bjam then it uses the
>>> native 64-bit compiler, and everything is OK.
>>>
>>
>> I thought there's only one way to build bjam - by running
>> tools/build/src/engine/build.bat. That's how I've always been building it
>> anyway, and it always produced a 32-bit binary. How do you build a 64-bit
>> bjam?
>>
>>
> This problem will occur (with msvc-14.0) when using the bootstrap.bat file
> specified in the getting started directions.

Do you mean that it is a problem if bootstrap.bat picks msvc-14.0 as the
"default" to use to bootstrap Boost build on Windows ?

Actually I have never really understand how bootstrap.bat picks a
default compiler in order to bootstrap Boost build. Do you know ?



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Marshall Clow-2
In reply to this post by John Maddock-2
On Fri, Aug 7, 2015 at 11:21 AM, John Maddock <[hidden email]>
wrote:

>
>
> On 07/08/2015 17:24, Andrey Semashev wrote:
>
>> On 07.08.2015 19:09, John Maddock wrote:
>>
>>> What are the steps to reproduce this? 64-bit msvc-14 builds seem to be
>>> OK for me,
>>>
>>
>> I described my steps at the beginning of the thread:
>>
>>
>> http://boost.2283326.n4.nabble.com/build-Problems-with-VC14-and-MSPDB140-DLL-was-testing-teeks-MSVC-14-errors-about-MSPDB140-DLL-td4678359.html
>>
>> Did you remove the b2_msvc_14.0_vcvarsall* files in your temp directory?
>>
>>
> Got it, can confirm it's an issue when building with 32-bit bjam (which
> uses the cross compiler), if you build with 64-bit bjam then it uses the
> native 64-bit compiler, and everything is OK.
>
> IMO we should find a way to fix this.  John.
>
>
Everyone --

What is the status of this issue?

-- Marshall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Andrey Semashev-2
On Mon, Aug 10, 2015 at 6:34 PM, Marshall Clow <[hidden email]> wrote:

> On Fri, Aug 7, 2015 at 11:21 AM, John Maddock <[hidden email]>
> wrote:
>
>>
>>
>> On 07/08/2015 17:24, Andrey Semashev wrote:
>>
>>> On 07.08.2015 19:09, John Maddock wrote:
>>>
>>>> What are the steps to reproduce this? 64-bit msvc-14 builds seem to be
>>>> OK for me,
>>>>
>>>
>>> I described my steps at the beginning of the thread:
>>>
>>>
>>> http://boost.2283326.n4.nabble.com/build-Problems-with-VC14-and-MSPDB140-DLL-was-testing-teeks-MSVC-14-errors-about-MSPDB140-DLL-td4678359.html
>>>
>>> Did you remove the b2_msvc_14.0_vcvarsall* files in your temp directory?
>>>
>>>
>> Got it, can confirm it's an issue when building with 32-bit bjam (which
>> uses the cross compiler), if you build with 64-bit bjam then it uses the
>> native 64-bit compiler, and everything is OK.
>>
>> IMO we should find a way to fix this.  John.
>>
>>
> Everyone --
>
> What is the status of this issue?

I don't remember anyone fixing it, and 1.59 RC2 indeed fails to
compile for me, so the problem persists. For the reference, this is
what I did:

1. Download and unpack RC2.
2. Run bootstrap.bat, it builds 32-bit bjam and b2.
3. Run bjam.exe -j 4 --build-type=complete toolset=msvc variant=debug
threading=multi debug-symbols=on link=shared runtime-link=shared
address-model=64 libs/log/test

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Andrey Semashev-2
In reply to this post by Vladimir Prus-4
On Tue, Jul 28, 2015 at 9:49 AM, Vladimir Prus <[hidden email]> 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?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Andrey Semashev-2
On Mon, Aug 10, 2015 at 9:35 PM, Andrey Semashev
<[hidden email]> wrote:

> On Tue, Jul 28, 2015 at 9:49 AM, Vladimir Prus <[hidden email]> 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?

I created a Connect ticket about it:

https://connect.microsoft.com/VisualStudio/feedback/details/1651822/incorrect-mspdb140-dll-version-picked-in-x86-x64-cross-tools-environment

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Glen Fernandes
On Mon, Aug 10, 2015, Andrey Semashev wrote:
> I created a Connect ticket about it:
> https://connect.microsoft.com/VisualStudio/feedback/details/1651822/incorrect-mspdb140-dll-version-picked-in-x86-x64-cross-tools-environment

Are bugs being deleted? I see it on Google's cache:
http://tinyurl.com/nvedtmd

But the Connect URL now says "Page Not Found".

Glen

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Stephan T. Lavavej-2
[Andrey Semashev]
> I created a Connect ticket about it:
> https://connect.microsoft.com/VisualStudio/feedback/details/1651822/incorrect-mspdb140-dll-version-picked-in-x86-x64-cross-tools-environment

[Glen Fernandes]
> Are bugs being deleted? I see it on Google's cache:
> http://tinyurl.com/nvedtmd
> But the Connect URL now says "Page Not Found".

The link is also inaccessible to me, but it was successfully replicated to DevDiv#1209792 in TFS and remains active there.

STL

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Gavin Lambert
In reply to this post by Andrey Semashev-2
On 11/08/2015 06:35, Andrey Semashev wrote:
> 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?

One question is why Boost is trying to load the cross tools rather than
the native x64 compiler.

While it's not unheard of to want to build 64-bit code from a 32-bit
build machine, the vast majority of cases will be the reverse, so the
native compilers should be preferred unless explicitly requested otherwise.

(Recent stats say that 92% of new Windows machines are 64-bit; older
machines have a higher percentage of 32-bit but it's very likely that
developers, at least, will have 64-bit machines by now.)



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Gavin Lambert
Mere moments ago, quoth I:

> On 11/08/2015 06:35, Andrey Semashev wrote:
>> 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?
>
> One question is why Boost is trying to load the cross tools rather than
> the native x64 compiler.
>
> While it's not unheard of to want to build 64-bit code from a 32-bit
> build machine, the vast majority of cases will be the reverse, so the
> native compilers should be preferred unless explicitly requested otherwise.
>
> (Recent stats say that 92% of new Windows machines are 64-bit; older
> machines have a higher percentage of 32-bit but it's very likely that
> developers, at least, will have 64-bit machines by now.)

Ok, examining msvc.jam I think I've found the issue.  It defaults to
"x86_amd64" (cross compiler), and then swaps this to "amd64" (native
compiler) if the environment variable PROCESSOR_ARCHITECTURE is set to
AMD64.

However this will only be the case if the process executing the jam file
is also 64-bit.  A 32-bit process running under WOW64 will see "x86" for
that environment variable, just like it would on 32-bit Windows.

So, either Boost.Build itself needs to be a 64-bit process, or it needs
to be more clever at detecting a 64-bit architecture even as a 32-bit
process.  The simplest way of doing the latter is to read
PROCESSOR_ARCHITEW6432, which will be unset for native 32 or 64-bit and
set to AMD64 on 32-bit WOW64.  (ie. the jamfile should assume native
64-bit if either of PROCESSOR_ARCHITECTURE or PROCESSOR_ARCHITEW6432 are
set to AMD64.)



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
12