Sorry I didn't respond sooner, I must have missed that message on the list. As best I can tell, something is corrupt on the msvc-9.0 install on that VM. All the other runs on that VM (teeks99-09*) are using the same base repo to clone off of, so it isn't something in the boost filesystem. If you're looking for other msvc-9.0 results, see teeks99-08b. It *should* be the identical configuration, but appears not to have this problem. The MSVC-15 issue is known, I believe we are waiting for a build of B2 in develop that supports msvc-15.0 - Preview 5. Tom On Thu, Nov 3, 2016 at 5:04 AM, Andrey Semashev wrote:

...

Hi,

I see lots of tests failing on teeks99-09b-win2012R2-64on64, MSVC-9.0 because winerror.h is missing. Here's an example:

http://www.boost.org/development/tests/develop/developer/ output/teeks99-09b-win2012R2-64on64-boost-bin-v2-libs-log- test-src_logger_assignable-test-msvc-9-0-dbg-adrs-mdl-64-thrd-mlt.html

I can see that the file is present in Windows SDK 6.0A, which is supposed to be used with this compiler. The tests are passing on my machine.

Could this be a tester configuration issue?

Also, all MSVC-15 tests are failing on teeks99-09o-win2012R2-64on64 with

On Thu, Oct 27, 2016 at 12:41 PM, Andrey Semashev wrote: the

...

error of 'cl' not being found.

Ping?

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

On 11/16/16 15:08, Tom Kent wrote:

On Sun, Nov 6, 2016 at 5:46 PM, Tom Kent wrote:

...

Sorry I didn't respond sooner, I must have missed that message on the list.

As best I can tell, something is corrupt on the msvc-9.0 install on that VM. All the other runs on that VM (teeks99-09*) are using the same base repo to clone off of, so it isn't something in the boost filesystem. If you're looking for other msvc-9.0 results, see teeks99-08b. It *should* be the identical configuration, but appears not to have this problem.

The MSVC-15 issue is known, I believe we are waiting for a build of B2 in develop that supports msvc-15.0 - Preview 5.

I just wiped the VM and started with a fresh image, this should be better now.

Thanks, I can see the tests are turning green.

On Tue, Dec 6, 2016 at 10:26 AM, Andrey Semashev wrote:

On 11/16/16 15:17, Andrey Semashev wrote:

...

On 11/16/16 15:08, Tom Kent wrote:

...

On Sun, Nov 6, 2016 at 5:46 PM, Tom Kent wrote:

Sorry I didn't respond sooner, I must have missed that message on the

...

list.

As best I can tell, something is corrupt on the msvc-9.0 install on that VM. All the other runs on that VM (teeks99-09*) are using the same base repo to clone off of, so it isn't something in the boost filesystem. If you're looking for other msvc-9.0 results, see teeks99-08b. It *should* be the identical configuration, but appears not to have this problem.

The MSVC-15 issue is known, I believe we are waiting for a build of B2 in develop that supports msvc-15.0 - Preview 5.

I just wiped the VM and started with a fresh image, this should be better now.

Thanks, I can see the tests are turning green.

I think, the problem has returned. I'm seeing the same kind of failures on teeks99-09b-win2012R2-64on64:

http://www.boost.org/development/tests/develop/developer/out put/teeks99-09b-win2012R2-64on64-boost-bin-v2-libs-log-test- src_logger_assignable-test-msvc-9-0-dbg-adrs-mdl-64-thrd-mlt.html

Hmm, interesting. I had just added the Visual Studio 2017 RC back on to that machine, apparently that does something to break Visual Studio 2008??? I need to look into this, but now sure when I'll be able to or what I will be able to find. Tom

On Tue, Jan 10, 2017 at 10:18 AM, Andrey Semashev

wrote:

On 12/07/16 06:36, Tom Kent wrote:

...

On Tue, Dec 6, 2016 at 10:26 AM, Andrey Semashev < andrey.semashev@gmail.com> wrote:

On 11/16/16 15:17, Andrey Semashev wrote:

...

On 11/16/16 15:08, Tom Kent wrote:

...

On Sun, Nov 6, 2016 at 5:46 PM, Tom Kent wrote:

...

Sorry I didn't respond sooner, I must have missed that message on the

...

list.

As best I can tell, something is corrupt on the msvc-9.0 install on that VM. All the other runs on that VM (teeks99-09*) are using the same base repo to clone off of, so it isn't something in the boost filesystem. If you're looking for other msvc-9.0 results, see teeks99-08b. It *should* be the identical configuration, but appears not to have this problem.

The MSVC-15 issue is known, I believe we are waiting for a build of B2 in develop that supports msvc-15.0 - Preview 5.

I just wiped the VM and started with a fresh image, this should be

better now.

Thanks, I can see the tests are turning green.

I think, the problem has returned. I'm seeing the same kind of failures on teeks99-09b-win2012R2-64on64:

http://www.boost.org/development/tests/develop/developer/out put/teeks99-09b-win2012R2-64on64-boost-bin-v2-libs-log-test- src_logger_assignable-test-msvc-9-0-dbg-adrs-mdl-64-thrd-mlt.html

Hmm, interesting. I had just added the Visual Studio 2017 RC back on to that machine, apparently that does something to break Visual Studio 2008??? I need to look into this, but now sure when I'll be able to or what I will be able to find.

So, any progress about this?

Would it be possible to move unreleased compilers to a separate environment?

After further investigating this (sorry it took so long), it doesn't appear to be an issue with the visual studio install, as far as I can tell. For those just joining the thread (I've CCed boost-build list), a while back we noticed that my teeks99-02b (msvc-9.0) run was failing nearly every test in the regression matrix (at least those that had any windows.h dependency). At first I had no idea why, so I reloaded the VM from a previous image (this image includes msvc-8.0 through msvc-14.0), after the re-load everything was good for a while. A few weeks later, I installed the new Visual Studio 2017 RC (i.e. msvc-15.0, I believe?) and immediately the msvc-9.0 build started to fail again, in the same manner. At this point I remembered that I *had* installed an early beta of Visual Studio 2017 on the VM previously, which in hind-site was also causing the earlier problems. Today, I spent a little time on the VM trying to determine what was broken about the msvc-9.0 install. And my conclusion is that nothing is wrong and it is working fine! All the projects that I attempted to build with it went fine. Thus, I'm adding boost-build to the list, because I believe that there is something in our build configuration that is causing the problem. I'm not sure how to start debugging this however, so I was hoping for some pointers from those with more experience in boost-build. I believe that Visual Studio 2017 is going to be released next week, so it would be nice to get rid of this regression before then. I've got the build log from a teeks99-02b run here: https://gist.github.com/teeks99/29866e0b99b9863f3017ab898a2afd19#file-build_... I also have a copy of the results-bjam.log file, but it is too big to put into the gist. Thanks, Tom

On Sat, Feb 4, 2017 at 5:00 PM, Andrey Semashev 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: # Starting tests ("D:\teeks99-09\run\boost_bb\src\engine\bin.ntx86\bjam.exe" "-sBOOST_BUILD_PATH=D:\teeks99-09\run;D:\teeks99-09\run\boost_bb\src" "-sBOOST_ROOT=D:\teeks99-09\run\boost_root" "--boost=D:\teeks99-09\run\boost_root" "--boost-root=D:\teeks99-09\run\boost_root" "--boost-build=D:\teeks99-09\run\boost_bb\src" "--debug-configuration" -l300 toolset=msvc-9.0 -d2 preserve-test-targets=off --dump-tests -j8 address-model=64 --remove-test-targets --abbreviate-paths -m64 "--build-dir=D:\teeks99-09\run\results"

...

"D:\teeks99-09\run\results\bjam.log" 2>&1)... D:\teeks99-09\run\boost_root\status>"D:\teeks99-09\run\boost _bb\src\engine\bin.ntx86\bjam.exe" "-sBOOST_BUILD_PATH=D:\teeks99 -09\run;D:\teeks99-09\run\boost_bb\src" "-sBOOST_ROOT=D:\teeks99-09\run\boost_root" "--boost=D:\teeks99-09\run\boost_root" "--boost-root=D:\teeks99-09\run\boost_root" "--boost-build=D:\teeks99-09\run\boost_bb\src" "--debug-configuration" -l300 toolset=msvc-9.0 -d2 preserve-test-targets=off --dump-tests -j8 address-model=64 --remove-test-targets --abbreviate-paths -m64 "--build-dir=D:\teeks99-09\run\results" 1>>"D:\teeks99-09\run\results\bjam.log" 2>&1

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? Tom

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

On 02/11/17 05:06, Tom Kent via Boost wrote:

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.

I'm wondering if you have done that, because now the tests are failing with a linker error, rather than a compiler error: LINK : fatal error LNK1104: cannot open file 'kernel32.lib' http://www.boost.org/development/tests/develop/developer/output/teeks99-09b-...