Build as administrator is required on windows (sometimes?) #4440
Comments
|
Well, the error is a compiler error, not an SCons error - SCons has found and executed a compiler binary. It seems it's trying to create a file somewhere that it hasn't the rights to, which is why running with admin rights helps. I'd be looking at the settings of environment variables There are other ways to specify the version you want to use, though those have evolved somewhat since 4.0, so you shouldn't have to resort to your own call to vswhere (scons is going to do that anyway) but that's not the problem since you've shown it's finding it already, since 14.2x is the 2019 series.
Out of curiosity, why make it so complicated? @jcbrill any thoughts here? |
@mwichmann I set it up to just run scons from the shell in the appropriate python environment. At some point I took on other responsibilities and someone else made that change, and I don't know why, unfortunately. But I am still asked for help by users when the build system doesn't work since I created it initially. |
|
Not much to add yet. This thread seems to be similar:
At present, it sounds like a Windows environment issue. In addition to checking that the https://stackoverflow.com/questions/52152923/vs2017-build-returns-d8050-failed-to-get-command-line-into-debug-records |
|
SCons made this change:
way back in
The change to automatically propagate |
|
|
Yes, I think it missed the 4.3.0 release by a couple of weeks. diff --git a/SCons/Platform/win32.py b/SCons/Platform/win32.py
index eeb2abff4..990794f96 100644
--- a/SCons/Platform/win32.py
+++ b/SCons/Platform/win32.py
@@ -381,7 +381,7 @@ def generate(env):
# for SystemDrive because it's related.
#
# Weigh the impact carefully before adding other variables to this list.
- import_env = ['SystemDrive', 'SystemRoot', 'TEMP', 'TMP' ]
+ import_env = ['SystemDrive', 'SystemRoot', 'TEMP', 'TMP', 'USERPROFILE']
for var in import_env:
v = os.environ.get(var)
if v: |
|
Typical
Typical
If the User Variable |
|
Try upgrading to latest SCons... |
|
The windows environment issue experienced is reproducible when both If either FAILS from a "normal" windows command-line prompt without PASSES from an admin windows command prompt without PASSES from a "normal" command-line prompt with either Edits:
|
If |
I don't see that he said those aren't defined..? |
That was us running off and speculating on possible causes, and now testing (thanks @jcbrill for confirming which case it - likely - is) based on some other instances of similar. |
|
Research notes thus far based on the issue report above, search results, msvc documentation, and command-line experiments for posterity. There appears to be a confluence of events based on the windows environment and an msvc debug build that can result in build failures:
This is not specific to SCons and can be reproduced in a windows command-line environment. The behavior experienced is exactly the same as described in the second and third items below. Background information:
While there does not appear to be specific documentation for Test methodology for windows environment without SCons for failed build:
Procmon excerpts for a failed build: The attempt to create a file for writing in Test methodology for admin windows environment without SCons for successful build:
Procmon excerpts from a successful build: The attempt to create a file for writing in The The environment variable This succeeds in an admin command interpreter due to the ability to read/write into the |
|
Seems like the user should FIRST try upgrading to latest SCons which we know has better MSVC logic and then we can spend any time trying to debug their issue.. |
|
@jcbrill @bdbaddog @mwichmann |
Are they running these from powershell or cmd.exe shell? We have seem weird issues in the past where anti-virus could impact such things. So the original user no longer has the issue, but another user does and it's currently reproducible? Can you share the most minimal SConstruct which reproduces this? Would that do it? |
|
The installed Visual Studio version number might be helpful as well (e.g., 16.1, 16.2). Is vs2019 updated to the latest version? |
The original error message posted above in Nov 2023 shows toolset version 14.20.27508 which is a very early 2019 toolset and possibly the very first toolset. The latest toolset version for 2019 is 14.29.30133. Have updates to VS2019 been applied after the initial installation? Note that the v142 tools can be used in VS2022 by using the MSVC_TOOLSET_VERSION construction variable: Environment(MSVC_VERSION='14.3', MSVC_TOOLSET_VERSION='14.2', ...) |
|
It took us a while but we just migrated our windows toolchain to vs2022. Some users continue to see this problem with scons 4.8. See below: The affected user is able to build successfully when running scons from an admin command prompt. |
cmd.exe (but the user can reproduce the issue in powershell), python venv, not in docker.
We can't change our antivirus settings, the windows settings are controlled by our IT
As far as I can tell the issue is reproducible across reboots and is consistently reproducible
I would need some time but I think eventually I could produce something like that |
|
We'll look at it if there's any way to. On the antivirus topic: no idea if AV is at all involved in this problem (usually you'll get some less-than-helpful popups if so, so you'd probably know about it), but you really need to be able to whitelist a development tree, or it's going to be completely unworkable for devs. That's not anything particular to SCons. I've noticed one of the IDEs I use (the JetBrains family) detects if, once you've indicated you "trust" a project checkout, antivirus is going to be involved, it produces a program to add the whitelist settings and asks if you want to run it - so it's a widely recognized issue. I do see some evidence on people running into this, and nobody ever comes up with a very workable solution (usually something brute-force like "uninstall and reinstall Visual Studio, so the rights get reset". Here's a quite recent instance from Microsoft's own The issue in question is microsoft/vcpkg:38549 |
|
Here's the command line invocation (filename & libname obscured). As a sanity check, I verified that when running as admin, it is the same command line invocation to
cl : Command line error D8050 : cannot execute 'C:\ANSYSDev\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.36.32532\bin\HostX64\x64\c1xx.dll': failed to get command line into debug records |
|
@koubaa - in the corporate environments I've worked in, it's sometimes possible to get IT to temporarily disable A/V to see if it's contributing to such a problem. Did you try googling this issue? |
|
@koubaa If possible, running the attached script on the host computer might provide additional useful information about the windows environment. Attached is scons-environ.zip which contains:
Run the attached script on the host computer in the same windows shell environment that SCons is invoked and redirect the output to a file:
After reviewing the output file content for privacy, attach the output file. Notes:
Possible causes/resolutions from internet searches include:
The source code in its entirety: Sample output with |
|
I'll follow up on these. I was wondering if it was a race condition in how VS2022 uses TMP, and asked the affected user to use num_jobs=1, and the issue persists. |
|
|
@koubaa Sorry for the confusion with the implementation of the obfuscation. There is nothing that jumps out concerning the environment variable configuration. All the tests checks were done on the actual paths. The Some users are sensitive about having their username exposed. It certainly could have been done better. It might be worth checking the security/permissions settings on the It also might be worth testing settings of If a new temp folder is configured, the temp folder must exist. Note to self:
|
|
How much space is free on z: drive? |
|
|
@koubaa I've attached a revised version of the earlier script. At your convenience, I would be interested in knowing if it works somewhere other than here. scons-environ-2.zip contains a revised version of:
Run the attached script on the host computer in the same windows shell environment that SCons is invoked and redirect the output to a file: Changes:
Caveats:
Sample output when run on a local computer: |
|
Hello, After a conversation with the Microsoft compiler team they believe it is a problem with scons. To check, we looked at procmon system logs of all the process creations (which includes the environment variables that are set). Here is what I found (I use 1-based indexing for PIDs for simplicity) PID 1: In the above stack, only PID 8 does not have the TMP/TEMP environment variables set. Finally only the cmd.exe /C "cl.exe" does not have the environment variables set |
|
@koubaa When setting up Is there any chance that the setup is writing an empty string into the TEMP/TMP variable? Effectively: I believe the TEMP/TMP variables are only retrieved when the Environment is constructed. Any inadvertent overwrites by SCons-code and/or user-code would likely cause the behavior exhibited. |
|
This just seems really odd. The Windows platform code imports a few things specifically (with an admonition to consider carefully before adding more) - this is unrelated to whether or not the Microsoft compiler chain is even in use: import_env = ['SystemDrive', 'SystemRoot', 'TEMP', 'TMP', 'USERPROFILE']
for var in import_env: v = os.environ.get(var)
if v:
env['ENV'][var] = vSo the only way you wouldn't get TEMP/TMP set is if they weren't in the Windows environment, or were set to an empty value. But you're saying another tool in a failing environment does get them, so missing/unset doesn't seem like it can be the reason. Is there anything in your build that could possibly overwrite the |
|
I use this: The environment I pass to protoc is this:
maybe my issue is setting ENV on Environment in the first place. I could try removing that. |
|
Yes, setting that way sets the value of env = Environment(MSVC_USE_SCRIPT=vcvars_path)
env.AppendENVPath('PATH', protoc_path)
env.Tool('protoc')You may already be using it, if so never mind, but wanted to make sure you were aware there's a protoc tool in the Contrib repository ("unofficial", in other words) - https://github.com/SCons/scons-contrib/tree/master/sconscontrib/SCons/Tool/Protoc |
What is causing you to do the following? If you're passing the MSVC_SCRIPT, you shouldn't need it for MSVC at all.. |
|
Thanks for the sharing the protoc tool. It didn't exist when I first set this up. I don't do anything specifically for protoc. Actually the
using The env is indeed propagated to this tool, but I only use it to set up |
The problem was almost certainly "some tool was not found by SCons" even though it workd just fine when I launched it from cmd.exe. It's not like we haven't seen that many times before, it's just the Big Hammer approach of fixing it that way may have side effects.
Yes, that would bypass having lost the values expected to be in |
That's interesting. Does this mean that scons documentation mentions the |
It's in the FAQ.. |
|
To be clear the use of 'ENV' in our build system is not necessary to find protoc. I'm still trying to find out why it was done and I plan to remove it. But isn't it an issue if the scons FAQ suggests something which fails in such a subtle way when using a popular compiler (MSVC) ? |
Yes. |
That said.. this failure seems to be very rare in the wild. Also there is this warning in the FAQ |
I guess the warning could be stronger... |
That isn't the same failure mode. Here, an external environment variable was not propagated and should have been. |
Which one was it? I'm unclear.. |
|
Below is an example that intends to illustrate what is likely happening. In the interest of simplicity, only the MSVC tools are shown. Custom path additions would still need to be accounted for. Method:
For windows, the following environment variables are set prior to user overrides: "SystemDrive", "SystemRoot", "TMP", "TEMP", and "USERPROFILE". These variables are likely not set again. Method 1 below, similar to what you are experiencing, clobbers the predefined values by overwriting the entire The issue with method 1 is that the entire The issue with method 1 is that once the variables are overwritten, there is no way to "preserve" the original settings. All: please advise of any overt misinformation. |
|
@jcbrill - as usual.. Excellent explanation.. I was staring right at it and didn't see it! Thanks. |
|
For what it's worth, I had switched to method 3 which fixed the build as admin issue for the users that affected. But that broke a linux build for another user (scons couldn't find the compiler). Method 2 fixes that issue. Would it make sense for method 2 to appear in the FAQ rather than method 1? |
|
there's a faq update pending, just have to get the wheels turned |
SCons version: 4.0.1, installed via pip from pypi
Python 3.10 from python.org
Windows 10, Visual Studio 2019.
We use
MSVC_USE_SCRIPT=GetVCVarsPath(), function defined above. Users might also have Visual Studio 2022 installed, but this build requires VS2019.Describe the bug
I set up a scons-based build system at my organization. Some users have complained to me that they can only run the build as administrator. I am not able to reproduce that problem myself. Here is the error message that the users who are affected get when they build as a non-admin.
cl : Command line error D8050 : cannot execute 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.20.27508\bin\HostX64\x64\c1xx.dll': failed to get command line into debug records
scons: building terminated because of errors.
I can try to get a minimal reproducible example, but apparently any c++ scons build is affected for these users. We use Visual Studio 2019
scons is invoked from python in a virtual environment where scons is installed as a subprocess. The executable in the subprocess is determined using the result of the subprocess
where scons.The text was updated successfully, but these errors were encountered: