Re: [boost] Missing winerror.h for MSVC-9

On Tue, Feb 7, 2017 at 5:47 AM, Andrey Semashev wrote:

On 02/06/17 16:51, Tom Kent wrote:

...

On Sat, Feb 4, 2017 at 5:00 PM, Andrey Semashev < andrey.semashev@gmail.com> wrote:

On Sun, Feb 5, 2017 at 12:40 AM, Tom Kent wrote:

...

...

I've got the build log from a teeks99-02b run here: https://gist.github.com/teeks99/29866e0b99b9863f3017ab898a2a

fd19#file-build_output-log

Looking at the log above, it seems odd that MSVC *8.0* is used, not 9.0. Are you sure this is the correct log?

I'm not sure why you think that. The regression command definitely has --toolsets=msvc-9.0 and the important line(s) around 9388 are showing as running with msvc-9.0:

Oh, ok. I'm not familiar with the testing infrastructure and assumed MSVC 8 was used because the build log contains MSVC 8 build messages starting from line 8382. It's the build log for regression tools, and I assumed they were supposed to be built with the same toolset as the tests. Disregard my comment if that assumption is false.

Also, a random idea. You see that msvc.write-setup-script step in the

...

...

log? Could you verify that the cmd file for MSVC 9.0 in that directory contains the correct environment setup?

I think you may be on to something here. The file generated during the faulty (teeks99-09b) run: https://gist.github.com/teeks99/bd3ee6c93a8b4b8d4ec8defdfb20 6f3b#file-b2_msvc_9-0_vcvarsall_amd64-cmd

Is different from the file generated during the successful (teeks99-08b) run on a different VM (without VS 2017 RC installed): https://gist.github.com/teeks99/26e4dc5b8e98a5342da8368549512a 15#file-b2_msvc_9-0_vcvarsall_amd64-cmd

Specifically, the include path for the windows SDK isn't included. Looking at the "Visual Studio 2008 x64 Win64 Command Prompt" variables, the windows sdk path *does* show up there (and the native x86 command prompt and the cross compiler x64 command prompt) so something in the boost-build setup is not transferring that?

I'm not sure where to look from here, any ideas?

Well, my bjam-fu is not good enough to suggest something specific. The relevant code is in tools/build/src/tools/msvc.jam, the code that produces the scripts is in the maybe-rewrite-setup rule. It looks like the rule writes environment variables that become *different* after running the MSVC environment setup script. So, the fact that the variables are not written suggests that either those variables were already set before this rule was invoked (e.g. before bjam was executed) or the MSVC script failed to set them for some reason. In the latter case, maybe there's some permissions issue?

If you don't mind debugging, you could try to temporarilly modify the MSVC scripts to add debug output to discover the source of the problem. You will also probably have to modify generate-setup-cmd rule so that it doesn't discard the output but saves it into a file (see setup-suffix).

After many hours of debugging, I got to the issue. It isn't a boost issue, Microsoft *did* break VS 2008 (msvc-9.0) when you install Visual Studio 2017! I've detailed the bug here: https://connect.microsoft.com/VisualStudio/feedback/details/3121194 It only manifests itself when you try to set the visual studio environmental variables from a 32-bit shell (I ran my regression tests from a 32-bit python instance, which gives you a 32-bit shell the rest of the way down) and try to build 64-bit. The 32-bit version of the registry loses the *VALUE* for the key found by the command `reg query "HKLM\SOFTWARE\Microsoft SDKs\Windows" /v "CurrentInstallFolder"`. I'm going to move my regression runs to using python-64 bit, so that should fix things. Tom