[teeks] Missing winerror.h for MSVC-9
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-... 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 the error of 'cl' not being found.
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 <andrey.semashev@gmail.com> wrote:
On 11/16/16 15:17, Andrey Semashev wrote:
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/output/teeks99-09b-...
On Tue, Dec 6, 2016 at 10:26 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
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 <andrey.semashev@gmail.com
wrote:
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 Sun, Feb 5, 2017 at 12:40 AM, Tom Kent <lists@teeks99.com> wrote:
I've got the build log from a teeks99-02b run here: https://gist.github.com/teeks99/29866e0b99b9863f3017ab898a2afd19#file-build_...
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? 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?
On Sat, Feb 4, 2017 at 5:00 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
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"
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 02/06/17 16:51, Tom Kent wrote:
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.
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).
On Tue, Feb 7, 2017 at 5:47 AM, Andrey Semashev <andrey.semashev@gmail.com> 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. Tom
On 02/11/17 05:06, Tom Kent via Boost wrote:
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-...
participants (3)
-
Andrey Semashev -
Tom Kent -
Tom Kent