New install of Workbench on new Win 11 PC won't local compile simple sketch

Unable to compile anything.

:::: COMPILING APPLICATION & DEVICE OS

/bin/bash: C:/Users/Mark: No such file or directory
…/build/arm-tools.mk:120: *** "ARM gcc version 10.2.1 or later required, but found ". Stop.
make: *** [C:\Users\Mark Kiehl.particle\toolchains\buildscripts\1.11.0\Makefile:74: compile-all] Error 2

  • The terminal process “C:\Users\Mark Kiehl.particle\toolchains\buildtools\1.1.1\bin\bash.exe ‘-c’, ‘make -f ‘C:\Users\Mark Kiehl.particle\toolchains\buildscripts\1.11.0\Makefile’ compile-all -s’” terminated with exit code: 2.
  • Press any key to close the terminal.

This is a new Win 11 laptop with a new installation of Visual Studio Code v1.72.2. Initially I had a sketch folder ‘Particle’ under my ‘Documents’ folder, but then suspected that was the problem, so I moved it to C:\Particle. I completely uninstalled Visual Studio Code and deleted the following folders:
C:\Users\Mark Kiehl.vscode
C:\Users\Mark Kiehl.particle
C:\Users\Mark Kiehl\AppData\Local\particle

Reinstalled Visual Studio Code and then Particle Workbench. Created a new Particle project in ‘C:\Particle\boron_a\junk_b’. Logged in to Particle. Configured for device. Installed deviceOS@5.1.0 toolchain for boron. Then when I local compile, I experience the error:

/bin/bash: C:/Users/Mark: No such file or directory

(My user folder is C:/Users/Mark Kiehl/…)

I tried all other suggestions I could find, and everything else works fine until a local compile.

{
“username”: “markwkiehl@gmail.com”,
“workspace”: {
“name”: “junk_b”,
“isWorkspace”: false,
“folders”: [
{
“location”: “c:\Particle\boron_a\junk_b”,
“hasValidPath”: true,
“settings”: {
“firmwareName”: “deviceOS”,
“firmwareVersion”: “5.1.0”,
“targetDevice”: “boron_a”,
“targetPlatform”: “boron”,
“compileButtonAction”: “localAppDeviceOS”,
“flashButtonAction”: “localAppDeviceOS”,
“disableWelcomeScreen”: false,
“disableDeviceOSOutdatedCheck”: false,
“disableLocalCompilerDirtyCheck”: false,
“enableVerboseLocalCompilerLogging”: false,
“compileDefines”: ,
“customDeviceOSLocation”: “”,
“maxAllowedToolchains”: 4
},
“files”: [
“.vscode”,
“.vscode\launch.json”,
“.vscode\settings.json”,
“project.properties”,
“README.md”,
“src”,
“src\junk_b.cpp”,
“src\junk_b.ino”
]
}
]
},
“cli”: {
“binpath”: “c:\Users\Mark Kiehl\.vscode\extensions\particle.particle-vscode-core-1.15.5\src\cli\bin\windows\amd64\particle.exe”,
“ok”: true,
“version”: “3.5.0”,
“installed”: 1666636582888
},
“localCompiler”: {
“ok”: true,
“dependencies”: [
{
“id”: “deviceOS@5.1.0”,
“ok”: true
},
{
“id”: “gcc-arm@10.2.1”,
“ok”: true
},
{
“id”: “buildtools@1.1.1”,
“ok”: true
},
{
“id”: “buildscripts@1.11.0”,
“ok”: true
},
{
“id”: “openocd@0.11.0-particle.4”,
“ok”: true
},
{
“id”: “deviceOS@4.0.0”,
“ok”: true
}
]
},
“platform”: {
“os”: “windows”,
“type”: “Windows_NT”,
“release”: “10.0.22000”,
“arch”: “x64”,
“path”: {
“key”: “Path”,
“value”: “C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Users\Mark Kiehl\AppData\Local\Microsoft\WindowsApps;C:\Users\Mark Kiehl\AppData\Local\Programs\Microsoft VS Code\bin”,
“entries”: [
“C:\Windows\system32”,
“C:\Windows”,
“C:\Windows\System32\Wbem”,
“C:\Windows\System32\WindowsPowerShell\v1.0\”,
“C:\Windows\System32\OpenSSH\”,
“C:\Users\Mark Kiehl\AppData\Local\Microsoft\WindowsApps”,
“C:\Users\Mark Kiehl\AppData\Local\Programs\Microsoft VS Code\bin”
]
},
“homeDir”: “C:\Users\Mark Kiehl”,
“particleDir”: “C:\Users\Mark Kiehl\.particle”,
“particleToolchainDir”: “C:\Users\Mark Kiehl\.particle\toolchains”
},
“env”: {
“ALLUSERSPROFILE”: “C:\ProgramData”,
“APPDATA”: “C:\Users\Mark Kiehl\AppData\Roaming”,
“APPLICATION_INSIGHTS_NO_DIAGNOSTIC_CHANNEL”: “1”,
“CHROME_CRASHPAD_PIPE_NAME”: “\\.\pipe\crashpad_15552_ISTUXCVNRDFIWVYL”,
“CommonProgramFiles”: “C:\Program Files\Common Files”,
“CommonProgramFiles(x86)”: “C:\Program Files (x86)\Common Files”,
“CommonProgramW6432”: “C:\Program Files\Common Files”,
“COMPUTERNAME”: “LAPTOP-RHGDMS1V”,
“ComSpec”: “C:\Windows\system32\cmd.exe”,
“DriverData”: “C:\Windows\System32\Drivers\DriverData”,
“ELECTRON_RUN_AS_NODE”: “1”,
“HOMEDRIVE”: “C:”,
“HOMEPATH”: “\Users\Mark Kiehl”,
“LOCALAPPDATA”: “C:\Users\Mark Kiehl\AppData\Local”,
“LOGONSERVER”: “\\LAPTOP-RHGDMS1V”,
“NIEXTCCOMPILERSUPP”: “C:\Program Files (x86)\National Instruments\Shared\ExternalCompilerSupport\C\”,
“NUMBER_OF_PROCESSORS”: “16”,
“OneDrive”: “C:\Users\Mark Kiehl\OneDrive”,
“ORIGINAL_XDG_CURRENT_DESKTOP”: “undefined”,
“OS”: “Windows_NT”,
“Path”: “C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Users\Mark Kiehl\AppData\Local\Microsoft\WindowsApps;C:\Users\Mark Kiehl\AppData\Local\Programs\Microsoft VS Code\bin”,
“PATHEXT”: “.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC”,
“PROCESSOR_ARCHITECTURE”: “AMD64”,
“PROCESSOR_IDENTIFIER”: “AMD64 Family 23 Model 104 Stepping 1, AuthenticAMD”,
“PROCESSOR_LEVEL”: “23”,
“PROCESSOR_REVISION”: “6801”,
“ProgramData”: “C:\ProgramData”,
“ProgramFiles”: “C:\Program Files”,
“ProgramFiles(x86)”: “C:\Program Files (x86)”,
“ProgramW6432”: “C:\Program Files”,
“PSModulePath”: “C:\Program Files\WindowsPowerShell\Modules;C:\Windows\system32\WindowsPowerShell\v1.0\Modules”,
“PUBLIC”: “C:\Users\Public”,
“SESSIONNAME”: “Console”,
“SystemDrive”: “C:”,
“SystemRoot”: “C:\Windows”,
“TEMP”: “C:\Users\MARKKI~1\AppData\Local\Temp”,
“TMP”: “C:\Users\MARKKI~1\AppData\Local\Temp”,
“USERDOMAIN”: “LAPTOP-RHGDMS1V”,
“USERDOMAIN_ROAMINGPROFILE”: “LAPTOP-RHGDMS1V”,
“USERNAME”: “Mark Kiehl”,
“USERPROFILE”: “C:\Users\Mark Kiehl”,
“VBOX_MSI_INSTALL_PATH”: “C:\Program Files\Oracle\VirtualBox\”,
“VSCODE_AMD_ENTRYPOINT”: “vs/workbench/api/node/extensionHostProcess”,
“VSCODE_CODE_CACHE_PATH”: “C:\Users\Mark Kiehl\AppData\Roaming\Code\CachedData\d045a5eda657f4d7b676dedbfa7aab8207f8a075”,
“VSCODE_CWD”: “C:\Users\Mark Kiehl\AppData\Local\Programs\Microsoft VS Code”,
“VSCODE_HANDLES_UNCAUGHT_ERRORS”: “true”,
“VSCODE_IPC_HOOK”: “\\.\pipe\012e7699d56f966f1f9787c8374d18fd-1.72.2-main-sock”,
“VSCODE_NLS_CONFIG”: “{"locale":"en-us","availableLanguages":{},"_languagePackSupport":true}”,
“VSCODE_PID”: “15552”,
“windir”: “C:\Windows”
},
“versions”: {
“node”: “16.14.2”,
“v8”: “10.2.154.15-electron.0”,
“uv”: “1.43.0”,
“zlib”: “1.2.11”,
“brotli”: “1.0.9”,
“ares”: “1.18.1”,
“modules”: “106”,
“nghttp2”: “1.45.1”,
“napi”: “8”,
“llhttp”: “6.0.4”,
“openssl”: “1.1.1”,
“cldr”: “40.0”,
“icu”: “70.1”,
“tz”: “2022b”,
“unicode”: “14.0”,
“electron”: “19.0.17”,
“microsoft-build”: “15825693”
},
“vscode”: {
“appName”: “Visual Studio Code”,
“appRoot”: “c:\Users\Mark Kiehl\AppData\Local\Programs\Microsoft VS Code\resources\app”,
“machineId”: “2bc38df7f31b6d9d142320908140ec5d144363045063fcdb8f5f416aaa4e477d”,
“sessionId”: “3f0c2789-c165-4049-9c22-a423cae303df1666638225327”,
“version”: “1.72.2”
},
“extensions”: [
{
“id”: “ms-vscode-remote.remote-wsl-recommender”,
“version”: “0.0.17”
},
{
“id”: “ms-vscode.js-debug”,
“version”: “1.72.1”
},
{
“id”: “ms-vscode.js-debug-companion”,
“version”: “1.0.18”
},
{
“id”: “ms-vscode.vscode-js-profile-table”,
“version”: “1.0.3”
},
{
“id”: “marus25.cortex-debug”,
“version”: “1.6.6”
},
{
“id”: “ms-vscode.cmake-tools”,
“version”: “1.12.27”
},
{
“id”: “ms-vscode.cpptools”,
“version”: “1.12.4”
},
{
“id”: “ms-vscode.cpptools-extension-pack”,
“version”: “1.3.0”
},
{
“id”: “ms-vscode.cpptools-themes”,
“version”: “1.0.0”
},
{
“id”: “particle.particle-vscode-core”,
“version”: “1.15.5”
},
{
“id”: “particle.particle-vscode-pack”,
“version”: “1.15.5”
},
{
“id”: “particle.particle-vscode-snippets”,
“version”: “1.15.5”
},
{
“id”: “particle.particle-vscode-theme”,
“version”: “1.15.5”
},
{
“id”: “twxs.cmake”,
“version”: “0.0.17”
}
]
}

Windows 11 Home v 21H23

My user folder is C:/Users/Mark Kiehl/

sadly, spaces within file paths are not supported due to limitations in the underlying make build system:

No, my project path is now: C:\Particle\

Turning on logging, the problem seems to be related to the toolchain:

Executing task: make -f ‘C:\Users\Mark Kiehl.particle\toolchains\buildscripts\1.11.0\Makefile’ compile-all

:::: COMPILING APPLICATION & DEVICE OS

cd “C:/Users/Mark Kiehl/.particle/toolchains/deviceOS/5.1.0/modules” && make all
make[1]: Entering directory ‘/cygdrive/c/Users/Mark Kiehl/.particle/toolchains/deviceOS/5.1.0/modules’
/bin/bash: C:/Users/Mark: No such file or directory

I don’t know how to change the Particle Workbench installation so it doesn’t install anything into my user folder.

I looked over all of the similar posts and tried everything, but I still have the same problem. Changing my login name to remove the space is NOT an acceptable solution because it would require me to re-install nearly every other app (I spent two days configuring my new laptop). What I need is a way to install Particle Workbench into a different folder than under \Users[my name].

I have a project to work on for a client and no way to move forward.

My prior laptop had Windows 10, VSC 1.67.2, and Workbench v1.14.11 and worked without an issue.

ash-4.4$ make -f $PARTICLE_MAKEFILE help
make: C:/Users/Mark: No such file or directory
make: *** No rule to make target ‘C:/Users/Mark’. Stop.

bash-4.4$ echo $PARTICLE_MAKEFILE
C:/Users/Mark Kiehl/.particle/toolchains/buildscripts/1.11.0/Makefile
bash-4.4$ echo $PATH
/cygdrive/c/Users/Mark Kiehl/.vscode/extensions/particle.particle-vscode-core-1.15.5/src/cli/bin/windows/amd64:/cygdrive/c/Users/Mark Kiehl/.particle/toolchains/gcc-arm/10.2.1/bin:/usr/bin:/cygdrive/c/Users/Mark Kiehl/.particle/toolchains/openocd/0.11.0-particle.4/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/Windows/System32/OpenSSH:/cygdrive/c/Users/Mark Kiehl/AppData/Local/Microsoft/WindowsApps:/cygdrive/c/Users/Mark Kiehl/AppData/Local/Programs/Microsoft VS Code/bin

bash-4.4$ which particle
/cygdrive/c/Users/Mark Kiehl/.vscode/extensions/particle.particle-vscode-core-1.15.5/src/cli/bin/windows/amd64/particle

bash-4.4$ which arm-none-eabi-gdb
/cygdrive/c/Users/Mark Kiehl/.particle/toolchains/gcc-arm/10.2.1/bin/arm-none-eabi-gdb

bash-4.4$ arm-none-eabi-gdb --version
GNU gdb (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.1.90.20201028-git
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

SUGGESTION: Add something to Particle Benchmark install that checks to see if Windows user profile path has a space in it. If found, warn the user. That is the minimum that should be implemented.

I tried changing my Windows 11 user profile folder name to remove the space. It is an involved process that requires me to create a separate administrator user. In the end, I WAS UNABLE TO DO THE CHANGE, and then I could not get access to my Windows account.

Fortunately, I created a system restore point prior to this disaster, and used that to recover my account. I guess the only option is to create another user account with a name that doesn’t have a space in it and use that account solely for working with Particle Workbench.

Seriously disappointing.

1 Like

Hey, sorry about your issues.
I wonder if a symlink can help here. Not sure yet how, and not even sure if Windows today supports them in a proper way.

Maybe if you create a symlink of c:\Users\Mark Kieh that points to c:\Users\Mark this could work?
I guess you will need to move around/modify particle workbench config files.

Cheers

acknowledging this isn’t an ideal situation, the best, most-reliable option is to create a new local user profile without a space:

again, i understand that isn’t always possible or easy.

i can’t commit to a timeline for (hopefully) obvious reasons but know that we are aware of the issue and intend to address it ASAP.

thanks for the report and apologies for the bumps :pray:

Trying symbolic links was a good idea, but unfortunately it didn’t work. Windows 11 has better support for symbolic links, so I was hopeful. I created a soft symbolic link “Mark” for my user folder “Mark Kiehl”, tested it, and then installed Workbench. All Command Palette commands throw an error because they reference the folder “Mark Kiehl”. The potential solution would be to somehow force the Workbench installation to reference the folder for the user “Mark”, but no installation options.

Working out of a separate Windows account with a single word name is un unacceptable solution, and as I said before, renaming my existing username “Mark Kiehl” is not a solution. Am I the only Particle developer running in Windows??? I have client projects for the new Boron and no suitable development environment! What a disappointment. It’s looking easier to go to another product/platform than to continue to struggle with Particle. :frowning:

gusgonnet, I appreciate you trying to help me.

Hey, I believe there are plenty devs who use Windows, but you were one of the unlucky ones with a complicated use case.
Now one last more thing I would try in your setup is this, from what you describe.
I would:

  • uninstall the whole workbench and VS Code
  • delete the .vscode folder under the users/your user/.vscode or users/your user/.config/.vscode
  • delete the .particle from similar locations
  • reinstall particle workbench

I suspect the folder with spaces could be “locked” in one of the config files, or plainly the link thingy in Win does not work as I had hoped.

Crossing fingers,
Gustavo.

I did that at least a dozen times before. I just tried uninstalling VSCode and Workbench, then deleted all instances of .vscode, .particle, and particle and then installed VS Code and Workbench again. No change. I tried symbolic link too, but as expected that doesn’t solve the problem. Particle CLI wants to find folders under ‘…\users\User Name..’ but cannot because of the space in the user profile folder name.

I tried installing the Particle CLI manually and specifying a folder, but that was a disaster too.

Until a solution is put into place to specify an alternative location for the Workbench installation, please warn Windows users not to use WorkBench if their Windows profile name (and profile folder) has a space in it.

2 Likes

I find Linux and macOS to be far better development environments, but I understand that may not be an option for everyone.

Now that Nathan mentions Linux and Mac, it rings the bell:

is an installation on the Windows Subsystem for Linux (WSL) an option for you?

Install Linux on Windows with WSL

I also read somewhere that VS Code with a Microsoft remote ssh plugin can open the VS Code UI on Windows and the backend (server part of VS Code) could be running on WSL (or any other server, or even a docker container!).

And when I write that, are you VERY familiar with Docker? if so, you might have another option there.
Yeah, I know, it’s all work and it sucks. I’m aware.

1 Like

The plugin is here, and this is its architecture:

Or, inside a container:

Is there a solution for this? Is there anything I can test or help with to try to resolve it? I'm slightly desperate here.

Hi and welcome to the community!

There was a fix by Particle some time ago: