Subject: Re: [boost] Missing winerror.h for MSVC-9
From: Tom Kent (lists_at_[hidden])
Date: 2017-02-11 02:06:12
On Tue, Feb 7, 2017 at 5:47 AM, Andrey Semashev <andrey.semashev_at_[hidden]>
> On 02/06/17 16:51, Tom Kent wrote:
>> On Sat, Feb 4, 2017 at 5:00 PM, Andrey Semashev <
>> On Sun, Feb 5, 2017 at 12:40 AM, Tom Kent <lists_at_[hidden]> wrote:
>>>> I've got the build log from a teeks99-02b run here:
>>> 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:
>> Is different from the file generated during the successful (teeks99-08b)
>> run on a different VM (without VS 2017 RC installed):
>> Specifically, the include path for the windows SDK isn't included.
>> at the "Visual Studio 2008 x64 Win64 Command Prompt" variables, the
>> 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
>> 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
I've detailed the bug here:
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk