[BUG] 'CC' is not recognized as an internal or external command

[maxgerhardt]

Bug Description

Upon compilation, some (many?) users experience an error of the type

'CC' is not recognized as an internal or external command, operable program or batch file.

and report it to the PlatformIO forums.

Configuration Files

None relevant.

Steps to Reproduce

1. Freshly install PlatformIO VSCode extension, make sure no compiler (gcc) is in the global PATH
2. Clone Marlin
3. Try to build any environment

Expected behavior:

It builds beause it either can find the PlatformIO provided compiler, or gives a meaningful error message.

Actual behavior:

'CC' is not recognized as an internal or external command, operable program or batch file.
CalledProcessError: Command 'CC -DTARGET_STM32F1 -D__MARLIN_FIRMWARE__ -DHAVE_SW_SERIAL -DDEBUG_LEVEL=0 -DSS_TIMER=4 -DSTM32_FLASH_SIZE=512 -D__MARLIN_DEPS__ -w -dM -E -x c++ buildroot/share/PlatformIO/scripts/common-dependencies.h' returned non-zero exit status 1.:
  File "C:\users\henri\.platformio\penv\lib\site-packages\platformio\builder\main.py", line 168:
    env.SConscript(item, exports="env")
  File "C:\Users\Henri\.platformio\packages\tool-scons\scons-local-4.0.1\SCons\Script\SConscript.py", line 598:
    return _SConscript(self.fs, *files, **subst_kw)
  File "C:\Users\Henri\.platformio\packages\tool-scons\scons-local-4.0.1\SCons\Script\SConscript.py", line 287:
    exec(compile(scriptdata, scriptname, 'exec'), call_stack[-1].globals)
  File "C:\AAA\Marlin\buildroot\share\PlatformIO\scripts\common-dependencies.py", line 286:
    apply_features_config()
  File "C:\AAA\Marlin\buildroot\share\PlatformIO\scripts\common-dependencies.py", line 118:
    if not env.MarlinFeatureIsEnabled(feature):
  File "C:\Users\Henri\.platformio\packages\tool-scons\scons-local-4.0.1\SCons\Environment.py", line 219:
    return self.method(*nargs, **kwargs)
  File "C:\AAA\Marlin\buildroot\share\PlatformIO\scripts\common-dependencies.py", line 262:
    load_marlin_features()
  File "C:\AAA\Marlin\buildroot\share\PlatformIO\scripts\common-dependencies.py", line 250:
    define_list = subprocess.check_output(cmd, shell=True).splitlines()
  File "C:\Users\Henri\.platformio\python3\lib\subprocess.py", line 411:
    **kwargs).stdout
  File "C:\Users\Henri\.platformio\python3\lib\subprocess.py", line 512:
    output=stdout, stderr=stderr)

Additional Information

Often occurs as a topic in the PlatformIO forums, e.g.

• https://community.platformio.org/t/platformio-cannot-compile-marlin-for-the-lpc1769-environment/18088
• https://community.platformio.org/t/why-do-i-get-this-error-everytime-i-try-to-build-the-new-marlin-firmware/17547/13
• https://community.platformio.org/t/stm32f103rc-btt-512k-does-not-compile-in-vscode-platformio-ide/18270

The current code for finding the compiler was added in #18721

The PR by @rhapsodyv says that PlatformIO does not correctly expose the compiler in some cases on Windows (no further details or reproduction given though, so I can only guess the reproduction steps above). I can imagine that that can be the case in a first-install scenario when not even packages like toolchain-atmelavr (or the one for the platform) are downloaded yet.

In such a case though the compiler would be downloaded after a first initial build.

If PlatformIO still exposes an incorrect compiler path after that, then it must be a core bug and handled in https://github.com/platformio/platformio-core/issues.

In any case, if extracting the compiler path fails, the Marlin scripts should recognize that by catching the CalledProcessError exception thrown in the stacktrace above, and inform the user about the possibilities (do rebuild, install global GCC [which seems to always work]).

Possibly related issues are #18720 and #18959.

[rhapsodyv]

I can imagine that that can be the case in a first-install scenario when not even packages like toolchain-atmelavr (or the one for the platform) are downloaded yet.

It's weird. PIO will install toolchain before our script runs.

I just deleted all my toolchains and added a log to our build script, here:

> Executing task in folder Marlin: pio run <

Processing mega2560 (platform: atmelavr; board: megaatmega2560; framework: arduino)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Tool Manager: Installing toolchain-atmelavr @ ~1.50400.0
Unpacking  [####################################]  100%          
Tool Manager: toolchain-atmelavr @ 1.50400.190710 has been installed!
Verbose mode can be enabled via `-v, --verbose` option
>>>>>>>>>>>>>>>>>>>>>>>> running common-dependencies.py.   <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
CONFIGURATION: https://docs.platformio.org/page/boards/atmelavr/megaatmega2560.html
PLATFORM: Atmel AVR (2.2.0) > Arduino Mega or Mega 2560 ATmega2560 (Mega 2560)
HARDWARE: ATMEGA2560 16MHz, 8KB RAM, 248KB Flash
DEBUG: Current (simavr) On-board (simavr)
PACKAGES: 
 - framework-arduino-avr 5.0.0 
 - toolchain-atmelavr 1.50400.190710 (5.4.0)
Converting Marlin.ino
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 5 compatible libraries
Scanning dependencies...
Dependency Graph

As you can see, the toolchain is installed before. I will take a look how this behave on windows and check if it's a PIO issue or a bug in our build script.

There's a strong possibly of the users are using an outdated version that didn't properly search for the correct compiler (in old versions, we fail to find the compiler in some paths).

[maxgerhardt]

I've asked the latest poster that had this problem about the version and he says that it was a fresh git clone of the default branch (https://community.platformio.org/t/stm32f103rc-btt-512k-does-not-compile-in-vscode-platformio-ide/18270/7?u=maxgerhardt).

However in that particular thread the problem seems to have been that the toolchain download was corrupted. toolchain-gccarmnoneeabi was said to be installed but the arm-none-eabi-g++ executable was actually missing. (But such a check can also be added in the script for good measure I think, os.path.isfile() of where <toolchain> or something)

The question is whether that is the only case that that can occur, because in the first linked thread it was just reported to be working after install GCC (although that was also with the NXP platform and not STM32)

[rhapsodyv]

This is our code that search by the current PIO compiler:

Marlin/buildroot/share/PlatformIO/scripts/common-dependencies.py

Line 203 in ba2cadb

def search_compiler():

First, it checks for custom_gcc option. Then, it walks through every path on env['ENV']['PATH'], looking for env['PROJECT_PACKAGES_DIR'] (the path where the pio install the toolchains), when found, it list all files on that folder and search for files ending with g++ (or g++.exe on windows). It's pretty simple.

Is it possible that some users have a windows install and the compiler name not end with .exe!?

[maxgerhardt]

Is it possible that some users have a windows install and the compiler name not end with .exe!?

The compiler packages for Windows all have .exe endings for the programs, I've checked.

I'll check back with the user and let him execute the search script with a bit more verbose output.

import os 
import re
import time
Import("env")
#print(env.Dump())

# Find the current platform compiler by searching the $PATH
# which will be in a platformio toolchain bin folder
path_regex = re.escape(env['PROJECT_PACKAGES_DIR'])
gcc = "g++"
if env['PLATFORM'] == 'win32':
    path_separator = ';'
    path_regex += r'.*\\bin'
    gcc += ".exe"
else:
    path_separator = ':'
    path_regex += r'/.+/bin'

# Search for the compiler
time.sleep(1)
print("PATH: " + str(env['ENV']['PATH'].split(path_separator)))
for pathdir in env['ENV']['PATH'].split(path_separator):
    if not re.search(path_regex, pathdir, re.IGNORECASE):
        continue
    print("Searching directory: " + str(pathdir))
    for filepath in os.listdir(pathdir):
        print("Searching file " + filepath +  " (dir " + pathdir + ")")
        if not filepath.endswith(gcc):
            continue
        # Use entire path to not rely on env PATH
        filepath = os.path.sep.join([pathdir, filepath])
        print("Compiler found: " + str(filepath))
        env.Exit(0)
print("nothing found :(")
env.Exit(0)

Because for me that works really reliably, e.g.

PATH: ['C:\\Users\\Max\\.platformio\\packages\\tool-mklittlefs', 'C:\\Users\\Max\\.platformio\\packages\\tool-mkspiffs@1.200.0', 'C:\\Users\\Max\\.platformio\\packages\\tool-esptoolpy@1.20800.0', 'C:\\Users\\Max\\.platformio\\packages\\tool-esptool', 'C:\\Users\\Max\\.platformio\\packages\\toolchain-xtensa@2.40802.200502\\bin', 'C:\\Program Files (x86)\\Common Files\\Oracle\\Java\\javapath', 'C:\\Program Files\\AdoptOpenJDK\\jdk-11.0.9.11-hotspot\\bin', 'C:\\Program Files\\AdoptOpenJDK\\jre-11.0.9.11-hotspot\\bin', 'C:\\windows\\system32', 'C:\\windows', 'C:\\windows\\System32\\Wbem', 'C:\\windows\\System32\\WindowsPowerShell\\v1.0\\', 'C:\\windows\\System32\\OpenSSH\\', 'C:\\Program Files\\PuTTY\\', 'C:\\Program Files\\Microsoft VS Code\\bin', 'C:\\Program Files (x86)\\Gpg4win\\..\\GnuPG\\bin', 'C:\\Program Files\\dotnet\\', 'C:\\Program Files\\Microsoft SQL Server\\130\\Tools\\Binn\\', 'C:\\Program Files\\Microsoft SQL Server\\Client SDK\\ODBC\\170\\Tools\\Binn\\', 'C:\\Program Files\\Git\\cmd', 'C:\\Program Files\\mingw-w64\\x86_64-8.1.0-posix-seh-rt_v6-rev0\\mingw64\\bin', 'C:\\Program Files (x86)\\STMicroelectronics\\STM32 ST-LINK Utility\\ST-LINK Utility', 'C:\\Users\\Max\\Downloads\\gcc-arm-none-eabi-9-2020-q2-update-win32\\bin', 'C:\\Users\\Max\\Downloads\\GetGnuWin32Install\\bin', 'C:\\ProgramData\\chocolatey\\bin', 'C:\\Program Files\\nodejs\\', 'C:\\Program Files (x86)\\dotnet\\', 'C:\\Program Files (x86)\\Nordic Semiconductor\\nrf5x\\bin\\', 'C:\\Users\\Max\\Downloads\\ffmpeg-4.3.1-2020-11-19-full_build\\bin', 'C:\\Windows\\twain_32\\CNQ4200', 
'C:\\Windows\\twain_32\\CNQ_X64', 'C:\\Windows\\twain_32', 'C:\\Users\\Max\\AppData\\Local\\Programs\\Python\\Python38\\Scripts\\', 'C:\\Users\\Max\\AppData\\Local\\Programs\\Python\\Python38\\', 'C:\\Users\\Max\\AppData\\Local\\Microsoft\\WindowsApps', 'C:\\Users\\Max\\.dotnet\\tools', 'C:\\Users\\Max\\AppData\\Roaming\\npm']
Searching directory: C:\Users\Max\.platformio\packages\toolchain-xtensa@2.40802.200502\bin
Searching file xtensa-lx106-elf-addr2line.exe (dir C:\Users\Max\.platformio\packages\toolchain-xtensa@2.40802.200502\bin)
Searching file xtensa-lx106-elf-ar.exe (dir C:\Users\Max\.platformio\packages\toolchain-xtensa@2.40802.200502\bin)
Searching file xtensa-lx106-elf-as.exe (dir C:\Users\Max\.platformio\packages\toolchain-xtensa@2.40802.200502\bin)
Searching file xtensa-lx106-elf-c++.exe (dir C:\Users\Max\.platformio\packages\toolchain-xtensa@2.40802.200502\bin)
Searching file xtensa-lx106-elf-c++filt.exe (dir C:\Users\Max\.platformio\packages\toolchain-xtensa@2.40802.200502\bin)
Searching file xtensa-lx106-elf-cc.exe (dir C:\Users\Max\.platformio\packages\toolchain-xtensa@2.40802.200502\bin)
Searching file xtensa-lx106-elf-cpp.exe (dir C:\Users\Max\.platformio\packages\toolchain-xtensa@2.40802.200502\bin)
Searching file xtensa-lx106-elf-elfedit.exe (dir C:\Users\Max\.platformio\packages\toolchain-xtensa@2.40802.200502\bin)
Searching file xtensa-lx106-elf-g++.exe (dir C:\Users\Max\.platformio\packages\toolchain-xtensa@2.40802.200502\bin)
Compiler found: C:\Users\Max\.platformio\packages\toolchain-xtensa@2.40802.200502\bin\xtensa-lx106-elf-g++.exe

in even an ESP8266 project.

[rhapsodyv]

Yes, we had a few iterations on that code, until we reached this final version, that seems (?) to solve all issues.

I'm thinking to try use platformio run --target idedata to get compiler data instead of that search, but I didn't change it yet because it's working (?).

[rhapsodyv]

@maxgerhardt did you find anything? I didn't find any issue in my testes.

[maxgerhardt]

The user that had the initial error hasn't responded to my PMs yet that would have gotten debug logs sadly. The current code works for me, too.

[maxgerhardt]

Another user has the issue that a wrong path for avr-g++ is deduced. See https://community.platformio.org/t/issues-building-with-fresh-marlin-firmware-and-platformio-2-2-1/18552/24?u=maxgerhardt. The parsed path is just avr-g++, but without the actual path before it, like C:\Users\<user>\.platformio\toolchain-atmelavr. He said that Marlin was straight cloned from the default branch of this repo, just yesterday.

[maxgerhardt]

And another user just came in with the same problem: https://community.platformio.org/t/help-compiling-marlin-2-0-x-for-the-first-time/18610

[rhapsodyv]

By his log, he downloaded Marlin '2.0.x' branch, that really doesn't have all corrections!

@thinkyhead: can you merge this #19929 and #19881 on 2.0.x branch?

[simonsickle]

I replicated this by accident - my impatience turned out to be the cause here. The toolchain wasn't fully downloaded, but the system thought it was due the download being started. I deleted C:\Users\myuser\.platformio after closing VS Code. When I opened again, the download started and eventually asked to restart VS Code.

Basically, don't be impatient and it should compile fine in Windows.

[maxgerhardt]

I've seen at least one case where the toolchain binary was fully present though. I'll keep it in mind and recommend this to other users in the future though as a debugging step. The last user just reported that it works on a different PC (doesn't give the cause though). In the thread before that, the GCC invocation fails with non-zero error code unexplicably, because if one manually executes it, it executes OK (and no Antivirus software is installed..). So this is all pretty much a mystery to me.

[dnear1]

I was having the exact same issue (cc not recognized) with W10 and PlatformIO. Building the current Marlin 2.0.x release from Github. I deleted .platformio folder as @simonsickle suggested and I'm at least able to build an unmodified Marlin..

[reloxx13]

I had the same problem today, after debugging i found that the common-dependencies.py forces the packages to be in the PATH variable.

the ppl getting this error may have changed the directories, too. it worked months ago.

This makes overriding the packages dir invalid, cause the marlin project dir is not in PATH.

[platformio]
...
# custom override dirs
platforms_dir   = .pio/platforms
packages_dir    = .pio/packages
build_cache_dir = .pio/cache

I override the dirs, cause i dont want everything on my SSD.

the search_compiler function gets the env['PROJECT_PACKAGES_DIR']

why is it looping the PATH now? this makes no sense for me,
if the dev sets the packages dir, this one should be used without careingif its in PATH or not.
u could avoid the complete loop.

Marlin/buildroot/share/PlatformIO/scripts/common-dependencies.py

Lines 194 to 218 in 5ee1087

	path_regex = re.escape(env['PROJECT_PACKAGES_DIR'])
	gcc = "g++"
	if env['PLATFORM'] == 'win32':
	path_separator = ';'
	path_regex += r'.*\\bin'
	gcc += ".exe"
	else:
	path_separator = ':'
	path_regex += r'/.+/bin'
	# Search for the compiler
	for pathdir in env['ENV']['PATH'].split(path_separator):
	if not re.search(path_regex, pathdir, re.IGNORECASE):
	continue
	for filepath in os.listdir(pathdir):
	if not filepath.endswith(gcc):
	continue
	# Cache the g++ path to no search always
	if os.path.exists(ENV_BUILD_PATH):
	blab('Caching g++ for current env')
	with open(GCC_PATH_CACHE, 'w+') as f:
	f.write(filepath)
	return filepath

[rhapsodyv]

PIO will put the toolchain bin folder (where the compiler is located) in the path... the toolchain is installed in the packages dir... The PATH will have something like that: PATH=PACKAGES_DIR/toolchain-gcc-foo-bar/bin:ETC:ETC:ETC...

So we just look for GCC executable in the folders that are both in the packages dir and in the PATH.

I never edited packages_dir config, but I expect that it should reflect on env['PROJECT_PACKAGES_DIR']... Maybe the issue is relative VS absolute path for packages dir...

[reloxx13]

PIO will put the toolchain bin folder (where the compiler is located) in the path... the toolchain is installed in the packages dir... The PATH will have something like that: PATH=PACKAGES_DIR/toolchain-gcc-foo-bar/bin:ETC:ETC:ETC...

So we just look for GCC executable in the folders that are both in the packages dir and in the PATH.

I never edited packages_dir config, but I expect that it should reflect on env['PROJECT_PACKAGES_DIR']... Maybe the issue is relative VS absolute path for packages dir...

no, if u edit it like i did, PIO uses the abosulte path (D:\xampp\htdocs\Marlin\.pio\packages).

a overriden directory is NOT in PATH ( for me the default PIO packages dir was not, too, i re-added it)
EDIT: u r right, they are tempoary preappended to the default (windows) PATH while building.

[rhapsodyv]

What is in your PATH? The toolchain should be in your path in some way... If not, any build will fail, not only our script.

[CaptionAdam]

for me, it works until I change the board and environment in pio.ini then I get this error aswell

[rhapsodyv]

for me, it works until I change the board and environment in pio.ini then I get this error aswell

More info, please. Did you try delete your .pio folder? And your ~/.platformio/packages folder?

I'm keeping it open for a while, just gather more info. But until now, everything points that there's no bug at all. What is happening is partial download or corrupted pio installation.

[MendozaDOD]

I just fixed this exact issue -> I only had to delete the platformio folder from the extensions folder then reinstalled PlatformIO and restarted VS Code -> no more error :) I'm going to go with a corrupt installation for my case... After the second install I noticed I didn't receive the Restart notification on the first install. Hope this helps .

[CrashOverr]

I replicated this by accident - my impatience turned out to be the cause here. The toolchain wasn't fully downloaded, but the system thought it was due the download being started. I deleted C:\Users\myuser\.platformio after closing VS Code. When I opened again, the download started and eventually asked to restart VS Code.

Basically, don't be impatient and it should compile fine in Windows.

Works for my tooooo!!!!

[CoefficientofSquish]

I'm so glad I found this, it worked for me as well. I think when I very first started learning how to do this (which was only about 2 months ago) I created a virtual environment through the command line but I had no idea what I was doing and I think that might have been what got me off course because I've been compiling just fine on two other machines but on this one I have never gotten one successful compile until just now.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.