Local compile after Windows update to 2004 not working: make: command not found

After updating Windows to 2004, local compile in VSCode stopped working. It shows

> Executing task: make -f 'C:\Users\N\.particle\toolchains\buildscripts\1.9.2\Makefile' compile-user -s <

/usr/bin/bash: make: Kommando nicht gefunden.
The terminal process "C:\Users\N\.particle\toolchains\buildtools\1.1.1\bin\bash.exe '-c', 'make -f 'C:\Users\N\.particle\toolchains\buildscripts\1.9.2\Makefile' compile-user -s'" failed to launch (exit code: 127).

Looking at the PATH variable of the bash used there, .particle\toolchains\buildtools\1.1.1\bin is missing, so it does not find make.

I tried without success everything I found here in the community:

  • Deleting C:\Users\N\.particle and reinstalling the local compiler toolchain
  • Deleting C:\Users\N\AppData\Local\particle and reinstalling the CLI with the windows installer
  • Creating a new Particle project in VSCode
  • Reinstalling the VSCode plugins
  • Reset Environment
  • Audit Environment:
"localCompiler": {
        "ok": true,
        "dependencies": [
            {
                "id": "deviceOS@1.5.2",
                "ok": true
            },
            {
                "id": "gcc-arm@5.3.1",
                "ok": true
            },
            {
                "id": "buildtools@1.1.1",
                "ok": true
            },
            {
                "id": "buildscripts@1.9.2",
                "ok": true
            },
            {
                "id": "openocd@0.11.2-adhoc6ea4372.0",
                "ok": true
            }
        ]
    }

What else can I do?

Adding C:\Users\N\.particle\toolchains\buildtools\1.1.1\bin to the Windows PATH environment variable solved the problem.
Seems like the bash called for compilation uses the Windows PATH and the folder got removed somehow and not re-added.

Adding C:\Users\N\.particle\toolchains\buildtools\1.1.1\bin to the Windows PATH environment variable solved the problem.

you shouldn’t ever need to mess with your PATH. try the following:

  1. run the Particle: Launch Compiler Shell command
  2. in the terminal instance that launches, run env
  3. look for the PATH line in the data returned by env

you should see a string that starts with entries that look like:

PATH=/cygdrive/c/Users/me/.vscode/extensions/particle.particle-vscode-core-1.12.2/src/cli/bin/windows/amd64:/cygdrive/c/Users/me/.particle/toolchains/gcc-arm/9.2.1/bin:/usr/bin:/cygdrive/c/Users/me/.particle/toolchains/openocd/0.11.2-adhoc6ea4372.0/bin:<more records here>
  1. in that same terminal window, run: which make

you should get back:

/usr/bin/make

likewise, running which bash should give you /usr/bin/bash

After updating Windows to 2004

that could be the issue - run the Particle: Audit Environment command and share the platform and workspace fields. here are the important platform values as reported by my test machine:

"platform": {
    "os": "windows",
    "type": "Windows_NT",
    "release": "10.0.19041",
    "arch": "x64"
}

I have a similar, possibly related issue. No external dependencies, have been building for months - suddenly, everything is broken. When attempting a local compile:

':::: COMPILING APPLICATION
'DEVICE' is not recognized as an internal or external command,
operable program or batch file.
make: *** [compile-all] Error 1
The terminal process "C:\Users\Anthony\.particle\toolchains\buildtools\1.1.1\bin\bash.exe '-c', 'make -f 'C:\Users\Anthony\.particle\toolchains\buildscripts\1.9.2\Makefile' compile-all -s'" failed to launch (exit code: 2).

It’s also complained about not finding crc32 in other contexts.

Everything points to an issue with the PATH / environment not getting set correctly when using the makefile. In response to @m_m’s recommendations:

  • Running env in the “Compiler Shell” context just shows my normal Windows PATH, no cygdrive paths appended.
  • Running which make shows another GnuWin32 make I have on my usual PATH, not the cygwin make.

I did update to Windows 2004 about a month ago, but was successfully building for a couple weeks after that - so I’m hesitant to say this is related.

My platform information from the Audit Environment command are the same as @m_m’s above:

"platform": {
    "os": "windows",
    "type": "Windows_NT",
    "release": "10.0.19041",
    "arch": "x64"
}

Adding the Particle buildtools to my Windows PATH as @nils suggests temporarily resolves the issue, but isn’t a real solution - why is the Particle Makefile suddenly unable to properly set up its environment?

Thank you @m_m for the assistance. I removed the manually added path entry and tried what you suggested:

bash-4.4$ env
bash: env: Kommando nicht gefunden.
bash-4.4$ which make
bash: which: Kommando nicht gefunden.
bash-4.4$ which bash
bash: which: Kommando nicht gefunden.

Looking at PATH with echo $PATH, the only entry belonging to Particle is

/cygdrive/c/Users/N/AppData/Local/particle/bin

Audit Environment (some unimportant fields replaced by …):

"workspace": {
    "name": "...",
    "isWorkspace": false,
    "folders": [
        {
            "location": "c:\\Users\\N\\Documents\\Particle\\projects\\...",
            "hasValidPath": true,
            "settings": {
                "firmwareName": "deviceOS",
                "firmwareVersion": "1.5.2",
                "targetDevice": "...",
                "targetPlatform": "boron",
                "compileButtonAction": "localAppDeviceOS",
                "flashButtonAction": "localAppDeviceOS",
                "disableWelcomeScreen": true,
                "disableDeviceOSOutdatedCheck": false,
                "disableLocalCompilerDirtyCheck": true,
                "enableVerboseLocalCompilerLogging": false,
                "compileDefines": [],
                "customDeviceOSLocation": "",
                "maxAllowedToolchains": 4
            },
            "files": [...]
        }
    ]
},
"platform": {
    "os": "windows",
    "type": "Windows_NT",
    "release": "10.0.19041",
    "arch": "x64",
    "path": {
        "key": "Path",
        "value": "...;C:\\Users\\N\\AppData\\Local\\particle\\bin;...;C:\\Users\\N\\AppData\\Local\\particle\\bin;...;"
    },
    "homeDir": "C:\\Users\\N",
    "particleDir": "C:\\Users\\N\\.particle",
    "localCompilerToolchainDir": "C:\\Users\\N\\.particle\\toolchains"
}

You can try where instead of which
and instead of env try set

bash-4.4$ where make
INFORMATION: Es konnten keine Dateien mit dem angegebenen
Muster gefunden werden.

set shows the same PATH as echo $PATH.

That’s odd.
When I run these in VS Code on my Win10 2004 I get this

SYSTEMROOT='C:\WINDOWS'
...
TERM=cygwin
TERM_PROGRAM=vscode
TERM_PROGRAM_VERSION=1.49.0
TMP=/cygdrive/c/Users/me/AppData/Local/Temp
WINDIR='C:\WINDOWS'
_=env
bash-4.4$ where make
C:\Users\me\.particle\toolchains\buildtools\1.1.1\bin\make.exe
bash-4.4$ where bash
C:\Users\me\.particle\toolchains\buildtools\1.1.1\bin\bash.exe
C:\Windows\System32\bash.exe

and my path features numerous :/cygdrive/c/Users/... entries

I call the bash via “Launch Compiler Shell”, but:

bash-4.4$ where bash
C:\Windows\System32\bash.exe

set output looks different:

SYSTEMROOT='C:\WINDOWS'
...
TERM=cygwin
TERM_PROGRAM=vscode
TERM_PROGRAM_VERSION=1.48.2
TMP=/cygdrive/c/Users/N/AppData/Local/Temp
...
WINDIR='C:\WINDOWS'
_=bash

My PATH has 40 entries, all starting with /cygdrive/c/.... But the only one containing “particle” is /cygdrive/c/Users/N/AppData/Local/particle/bin.

My PATH has 40 entries

that could be the issue - windows places a limit on the total number of characters (iirc 4095). can you try removing as many of the entries as you can, rebooting, and trying again?

couldn’t hurt to update VSCode (current version as of today is v1.49.0). if you have a “stock” windows install around that you can install Particle Workbench on and then compare between installs, that’d probably help shed some light on things as well. beyond that, i’m stumped.

My PATH variable (in the compiler shell shown by echo $PATH or set) has a total length of 3305 characters. It contains 77 entries, of which 40 are unique (this was the number I mentioned). 37 entries are duplicates.
The PATH in the Windows environment variables settings has only 5 entries, which are part of the 40 entries in the compiler shell path. This is where I added C:\Users\N\.particle\toolchains\buildtools\1.1.1\bin to fix this issue.
image

Updating VSCode to 1.49.0 did not help. I don’t have another Windows machine here for comparing.

As VSCode with the Particle extensions are working on other Windows 10 2004 machines, this seems to be an individual problem with my installation. I think I have to reinstall VSCode, Particle drivers or ultimately windows.
But as the workaround with the addition to the Windows path is working fine and permanently across reboots, I think this is a valid solution for now.

Thank you all for the help!

I added C:\Users\N\.particle\toolchains\buildtools\1.1.1\bin to fix this issue.

while this might unblock you short-term, it’s not a long-term solution as we update the dependency from time to time (iow, the 1.1.1 (version) part of the path will change in the future).

I think I have to reinstall VSCode, Particle drivers or ultimately windows.

just to save you some effort, reinstalling - especially windows itself - will almost certainly not help.

i’m curious if you were running cygwin (or had it installed) prior to using Workbench?

under the hood, Workbench uses VSCode’s extension APIs (docs: 1, 2, 3) to spawn a terminal instance using cygwin’s bash with a number of environment variables (PATH, PARTICLE_MAKEFILE, etc) preconfigured based on your project’s configuration. it’s basically:

C:\Users\me\.particle\toolchains\buildtools\1.1.1\bin\bash.exe --noprofile --norc -c "make -f /path/to/makefile <selected-make-target> -s"

i’m not sure what would cause the behavior you are seeing where apparently PATH (and perhaps other environment variables) are not being set properly. i might open an issue over in the VSCode repo to see if they have any ideas - https://github.com/microsoft/vscode

either way, thanks for the report and apologies for the bumps :pray::+1:

I understand, so I will continue using the old path after an update, or it stops working again if the old path is removed.

Ok, but don’t you think there is a conflict with something that happened specifically on my machine at some point in the past?

I am not sure about this. I used cygwin a very long time ago, but I can not remember if it was my current (using since 2 years) or the last machine. But I can say for sure that I did not use cygwin ever since Particle Workbench has been released. cygwin is installed on my machine right now (startmenu entry).

Thank you again for the help! If you want to continue searching for the issue, I will provide the information you need, but I think I have to too little knowledge about the build plugins to open an issue at VSCode myself.

don’t you think there is a conflict with something that happened specifically on my machine at some point in the past?

yes, but it’s sort of overkill in that the issue almost certainly comes down to a weird configuration or conflicting software like…

cygwin is installed on my machine right now (startmenu entry).

Workbench doesn’t actually run the cygwin installer - it just drops the required subset of tools into the ~\.particle\toolchains\buildtools directory and references them as needed.

Maybe try running the uninstaller for cygwin (should be in that start menu entry somewhere) and see if things improve.

If you want to continue searching for the issue, I will provide the information you need,

thank you :pray:

but I think I have to too little knowledge about the build plugins to open an issue at VSCode myself.

understood :+1:

There is no uninstall entry image
and in “Apps & Features” in the system settings there is also no entry for cygwin, thus I can’t uninstall it. cygwin is located in C:\cygwin64

Setting my Windows PATH to include
C:\Users\ianda.particle\toolchains\buildtools\1.1.1\bin worked for me too as I simply do not have the time to investigate any further and have code to issue.

Perhaps the onus should be on Particle devs to investigate why their tools break?

To investigate the issue, they need information on how to reproduce this issue. What did you change on your system before the build stopped working?

1 Like

Windows auto update.

hey all - just to let you know, we’re working to reproduce and find the root-cause to this issue. i’ll report back as we learn more.

1 Like

update: thanks to @nils for helping me troubleshoot, we were able to confirm that the issue is being caused by a conflict between the PlatformIO extension and Workbench. it seems they released an update recently (September 10th) that likely introduced this issue. from what i’ve heard, prior versions worked fine alongside Particle Workbench.

short-term, the fix is to disable the PlatformIO extension and close + reopen VSCode.

i’ll try to diagnose the underlying problem and work with the PlatformIO and VSCode teams to get some sort of fix in place.

apologies for the bumps, thanks for you patience :pray:

3 Likes