Subject: Re: [boost] Missing winerror.h for MSVC-9
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2017-02-07 11:47:39
On 02/06/17 16:51, Tom Kent wrote:
> On Sat, Feb 4, 2017 at 5:00 PM, Andrey Semashev <andrey.semashev_at_[hidden]>
>> 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. 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).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk