Xtensa esp32 elf g error createprocess no such file or directory

I had a very long path, and there’s a file in there somewhere (not gcc.exe) but another file, that gcc.exe is accessing from the path..

So when I cleared the path, it worked

C:MinGW>cd bin


C:MinGWbin>where gcc.exe
C:MinGWbingcc.exe
C:Perl64sitebingcc.exe

^^ So running gcc from there will definitely run the ming gcc.exe

C:MinGWbin>type file6.c
#include<stdio.h>
void main()
{
int num1,num2;
scanf("%2d %4d",&num1,&num2);
printf("a=%d b=%d",num1,num2);
scanf("%d",&num1);
//flushall();
printf("c=%d",num1);
}

Compiling it I got this error

C:MinGWbin>gcc file6.c
gcc: error: CreateProcess: No such file or directory

My PATH was huge

C:MinGWbin>path
PATH=C:Windowssystem32;C:Windows;C:Windowssystem32wbem;C:P......

C:MinGWbin>path | grep -io «ming»

It didn’t have ming there.

C:MinGWbin>echo MING | grep -io «ming»
MING

(and yeah that grep works..the path didn’t have ming there)

Clearing my path completely, led it to work!

C:MinGWbin>set PATH=

C:MinGWbin>gcc file6.c

C:MinGWbin>

So, it’s not clear yet precisely what it was in the PATH that led to the clash. What directory, what file.

Update-

The above seems to be correct to me but to add, it’s also not a simple case of something earlier in the path clashing.. because normally the current directory takes precedence. And it does here in so far as gcc —version shows it’s running the ming one and not one of the ones in a conflicting directory. So there’s something funny going on that, if the conflicting directory is in the path) , one has to either do .gcc or add . to the start of the path or add c:MinGWbin before any conflicting directories in the path. this is the case even when you’re in C:MinGWbin and that’s strange. And when it gives an error, it is still running Ming’s gcc but (For some reason) looking at the conflicting directory too, as I see from process monitor. There may be more of an answer here http://wiki.codeblocks.org/index.php?title=Installing_MinGW_with_Vista in the link mentioned in the very upvoted answer here

That’s Ming32 bit..

Looking at Ming 64bit, probably has te same issue, but I see, interestingly, it comes with a bat file that (sensibly) actually puts the bin directory at the tart of the path. And it looks like that is a standard way of running Ming gcc properly.

The code::blocks IDE (sensibly) also puts the bin directory at the start of the path. If you run a C program that shows environment variables then you see that.

Xtensa esp32 elf g error createprocess no such file or directory

Post by perigalacticon » Mon Jan 01, 2018 4:03 am

But this is not true, this is not the usual sketchbook directory, usually it is:
C:/Users/[YOUR_USER_NAME]/Documents/Arduino/sketches.

Right now this is the directory structure:

See attached picture.

Re: xtensa-esp32-elf-g++»: file does not exist error; can’t compile, please help

Post by chegewara » Mon Jan 01, 2018 7:42 pm

Re: xtensa-esp32-elf-g++»: file does not exist error; can’t compile, please help

Post by perigalacticon » Mon Jan 01, 2018 11:08 pm

Re: xtensa-esp32-elf-g++»: file does not exist error; can’t compile, please help

Post by chegewara » Mon Jan 01, 2018 11:57 pm

Re: xtensa-esp32-elf-g++»: file does not exist error; can’t compile, please help

Post by perigalacticon » Tue Jan 02, 2018 1:04 pm

Re: xtensa-esp32-elf-g++»: file does not exist error; can’t compile, please help

Post by perigalacticon » Thu Jan 04, 2018 12:35 am

So I deleted the DocumentsArduinosketcheshardwareexpressif directory and re installed it to the DocumentsArduinohardware directory and now I have the expressifesp32tools directory; however, now there is NO LIST of ESP32 boards in the Boards Manager Menu. They were there when I installed it the sketches hardware directory, but not now. And I have restarted the IDE, and the computer.

I have another set of Arduino program directories at C:Program Files (x86)Arduino because it’s a 64bit machine and it makes you install it that way, however all of my sketches are in the Documents directory, but all of my libraries are in the x86 directory. So where exactly is this supposed to be installed, because it’s not working for me.

Re: xtensa-esp32-elf-g++»: file does not exist error; can’t compile, please help

Post by leovzz » Sun Jan 07, 2018 11:44 am

I have the same problem, however I think problem is related to get script failing dus to SSLerror

================
C:UsersleoDocumentsArduinohardwareespressifesp32tools>get
System: Windows, Info: Windows-10-10.0.16299
Platform: i686-mingw32
Downloading xtensa-esp32-elf-win32-1.22.0-75-gbaf03c2-5.2.0.zip
Traceback (most recent call last):
File «get.py», line 139, in
get_tool(tool)
File «get.py», line 89, in get_tool
r = requests.get(url)
File «site-packagesrequestsapi.py», line 70, in get
File «site-packagesrequestsapi.py», line 56, in request
File «site-packagesrequestssessions.py», line 488, in request
File «site-packagesrequestssessions.py», line 609, in send
File «site-packagesrequestsadapters.py», line 497, in send
requests.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)
Failed to execute script get
=================

Did run get as administrator.

Re: xtensa-esp32-elf-g++»: file does not exist error; can’t compile, please help

Post by jgripp » Sun Jan 14, 2018 12:12 am

I see same issue 1/13/18 when trying to upload WiFiScanner sketch to Heltec esp32 LoRa board using Arduino IDE 1.8.5.

Tend to agree with leovzz as the esp32 Git repo set does not include directory to or xtensa-esp32-elf-g++ file.

Appears that get.py command adds files to esp32 needed for upload to the HW library.

Per other recent bug post, get.py failing SSL file transfer.

Hope to see progress with SSL fix.

Re: xtensa-esp32-elf-g++»: file does not exist error; can’t compile, please help

Post by perigalacticon » Sun Jan 14, 2018 12:57 am

Re: xtensa-esp32-elf-g++»: file does not exist error; can’t compile, please help

Post by jgripp » Sun Jan 14, 2018 6:57 am

I was able to successfully install the Arduino IDE for esp32 by following instructions in below youtube video.

Look at minute 2:45 in the video where get.exe is invoked from the windows directory vs. command line.

Command line window opened and was able to watch xtensa-esp32-elf-g++ and other files/directories download and extract.

This is the only difference from previous failed Arduino IDE setup attempts.

Источник

Xtensa esp32 elf g error createprocess no such file or directory

Post by tuskiomi » Sun Sep 24, 2017 6:12 pm

This is untrue as The path to component_Wrapper is «C:espIDFmake», which is the windows 10 equivalent of that cygwin style address..

What could be going wrong in this?

Re: The «xtensa-esp32-elf-gcc.exe» executable cannot find any files when using Make in windows.

Post by ESP_igrr » Sun Sep 24, 2017 6:19 pm

Re: The «xtensa-esp32-elf-gcc.exe» executable cannot find any files when using Make in windows.

Post by tuskiomi » Sun Sep 24, 2017 8:16 pm

Re: The «xtensa-esp32-elf-gcc.exe» executable cannot find any files when using Make in windows.

Post by ESP_Angus » Mon Sep 25, 2017 12:36 am

As per the link ESP_Igrr posted, the mismatch here is that you’re using a Cygwin «make» but the toolchains (xtensa-esp32-elf-*) are MINGW32-based. There’s no way around this without recompiling the cross-toolchains to be Cygwin-based instead of MINGW32-based. Because otherwise you have:

Cygwin IDF_PATH + Cygwin make + MINGW32 toolchain = Cygwin make generates Cygwin /cygpath paths that the toolchain doesn’t recognize.

C:/xyz IDF_PATH + Cygwin make + MINGW32 toolchain = ESP-IDF makefile converts C:/xyz to /c/xyz and then Cygwin make doesn’t recognise that path. Even if you take out that early conversion, at some later point Cygwin make would canonicalize that path to a Cygwin path and the toolchain would fail to recognize it.

I spent a significant amount of time last year trying to come up with a make system that supported both Cygwin & MINGW32 «make» with a MINGW32 toolchain, and couldn’t find any easy way (at least without shipping two toolchains). We chose to support a MINGW32-based cross-toolchain mostly for performance reasons.

Is there a reason you need to use a Cygwin-based make instead of a MINGW32-based make? What environment are you running in?

Re: The «xtensa-esp32-elf-gcc.exe» executable cannot find any files when using Make in windows.

Post by tuskiomi » Mon Sep 25, 2017 12:47 am

My first intuition was to use cygwin make when the makefile spit out an error saying to use cygwin style file paths for IDF_PATH. There is no restriction. I am using Windows 10 with eclipse oxygen for an IDE.

Re: The «xtensa-esp32-elf-gcc.exe» executable cannot find any files when using Make in windows.

Post by ESP_Angus » Mon Sep 25, 2017 1:35 am

Sorry, that’s my mistake when writing that warning message I used the wrong terminology. If you can launch mingw32 make (ideally you can use the MSYS2 environment we ship) then it should all work.

(The lack of traditional C:blah paths is because make also uses colons as a delimiter so it’s hard to reconcile the two.)

Re: The «xtensa-esp32-elf-gcc.exe» executable cannot find any files when using Make in windows.

Post by zekahh » Sun Apr 22, 2018 9:58 pm

Hi guys, I got this

eclipse_make.sh has been replaced with eclipse_make.py. Check the Windows Eclipse docs for the new command.
This shell script will continue to work until the next major release.
C:msys32homeuserespesp-idf/make/project.mk:101: *** IDF_PATH cannot contain colons. If overriding IDF_PATH on Windows, use MSYS Unix-style /c/dir instead of C:/dir. Stop.
Running make in ‘C:/msys32/home/user/esp/esp-idf-template’

how do you fix this?, I installed Msys32.

Источник

Xtensa esp32 elf g error createprocess no such file or directory

Post by NickVerlooy93 » Wed Jul 10, 2019 12:56 pm

I’ve installed esp-idf with success and played around with some examples like hello-world and blink.
This seems to work fine.

Now I’m trying to perform the play_mp3 example in esp-adf.
This isn’t working and I noticed the following:

/bin/sh: regel 0: cd: C:Usersnick.verlooyespesp-adf: No such file or directory
Toolchain path: /opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc
Toolchain version: esp32-2019r1
Compiler version: 8.2.0
Python requirements from C:/Users/nick.verlooy/esp/esp-idf/requirements.txt are satisfied.

I see the ‘no such file or directory’ popping up and I have no idea how to fix this. I’ve set the ADF_PATH correctly.
Does someone know where and how I can solve this? Hope this makes the play_mp3 example work properly.

Re: Unknown file or directory

Post by NickVerlooy93 » Thu Jul 11, 2019 8:07 am

Deleting some ‘shell’ word in the /esp-adf/project.mk file makes the error go away.

Thus, I changed:
ADF_VER := $(shell cd $ && git describe —always —tags —dirty)

into:
ADF_VER := $(cd $ && git describe —always —tags —dirty)

Not sure if the error is now solved since I get other warnings / errors right now and the play_music app still does not work.
This is what I get after doing the ‘make flash -j’ command:

Re: Unknown file or directory

Post by ESP_Sprite » Thu Jul 11, 2019 8:37 am

I think it’s a problem with backslash/slash usage. You said you set your paths correctly: did you use Windows-style backslashes there instead of Unix-style forward slashes? If so, you may want to remedy this. Also, deleting the shell statements is not a good idea: while it makes the error go away, it’s also breaking the intended functionality.

Re: Unknown file or directory

Post by NickVerlooy93 » Thu Jul 11, 2019 9:05 am

Thanks for your reply. This was indeed a problem.
I changed all backward into forward slashes.
Still wondering why this didn’t cause any problems in the ‘hello_world’ and ‘blink’ examples from the ESP_IDF.
I’ve also put back the shell words. Changing things inside the ‘source code’ is indeed not a good idea. Newbie mistake I guess.

Still, I’m not succeeding in the ‘play_mp3’ example. I get the following output with the ‘make’ command:
(All errors seem to be inside the esp/esp_adf folder)

Источник

Unable to compile ESP32 boards #3070

The problem

Seems some standard c++ libs are missing in esp32

Which version of ESPHome has the issue?

What type of installation are you using?

Which version of Home Assistant has the issue?

What platform are you using?

Board

Component causing the issue

Example YAML snippet

Anything in the logs that might be useful for us?

Additional information

All esp8266 boards I can compile with 2022.2.4 but none of the esp32’s will build

The text was updated successfully, but these errors were encountered:

Works for me.
Maybe the same as #3072 ?

on x86 host getting a different error

removed the entire /config/.esphome/platformio folder now getting different error

Remove the addon too, restart HA, reinstall.

Remove the addon too, restart HA, reinstall.

Just using plan docker in Kubernetes. So have restarted. Cleared platformio folder ran on both arm64 and x86_64. What I haven’t tried is downgrading and see if the issues go away

Just updated to 2022.2.5 and was able to compile all boards on arm64 host
I did end up having to remove the /config/.esphone/platformio folder

© 2023 GitHub, Inc.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

esp-2021r2-patch2-8.4.0 not working if user folder has a space in it (IDFGH-6735) #8364

Environment

• Development Kit: none
• Module or chip used: ESP32
• IDF version: v4.4
• Build System: CMake
• Compiler version : xtensa-esp32-elf-gcc (crosstool-NG esp-2021r2-patch2) 8.4.0
• Operating System: Windows
• (Windows only) environment type: idf.py
• Using an IDE?: Yes, Eclipse 2021-06 with esp-idf plugin

Problem Description

I’ve just updated a project from esp-idf-v4.3.2 to esp-idf-v4.4 and I have the following error message:

As you can guess, the user directory is «C:UsersMarco Mariotti», but somehow the space in it is no longer escaped.
The error was not present in esp-idf-v4.3.2 (using esp-2021r2-8.4.0 toolchain).

The text was updated successfully, but these errors were encountered:

Hi @apiesse, thanks for reporting this. It’s interesting to hear that having a directory with space in its path worked for you in older versions of ESP-IDF. This is explicitly not supported and there were several places in the build system where spaces were not handled correctly.
https://docs.espressif.com/projects/esp-idf/en/v4.4/esp32/get-started/index.html#step-1-install-prerequisites

We have fixed these issues in master recently and the future v5.0 release will support spaces in paths.

Could you please check the following:

• when you used v4.3.2, did ESP-IDF directory have path with spaces?
• did your project have path with spaces?

Thanks for the reply @igrr .
That surprised me as well give the IDE Tools are installed in C:espressif and the project is located in C:svnprojectfirmwaretrunkapp (same with esp-idf-v4.3.2) as the documentation suggested.

I see, looks like it might be a ccache issue. Are you building using idf.py build from command line or from an IDE?
If it’s the former, could you do set IDF_CCACHE_ENABLE=0 in the command prompt, then idf.py fullclean and finally idf.py build again.

This is working both from command line and Eclipse!
Thank you, hope to see this soon in some release before 5.0!

Thanks for confirming that disabling the cache helps.

I’m afraid we can’t add support for spaces in paths to existing v4.x release because it introduces certain breaking changes to project CMakeLists.txt files. So by fixing spaces in paths, we unfortunately also have a chance of breaking some projects. Because of that, we decided to include this change only in v5.0.

However the issue with ccache seems to be unrelated, and I think it can be fixed by upgrading ccache to a more recent version. We’ll try to reproduce the issue and upgrade ccache version in the existing v4.x releases.

In the meantime, you can re-enable ccache ( set IDF_CCACHE_ENABLE=1 ) and then configure ccache to use different cache directory — instead of somewhere in your home directory, point it e.g. to C:espressifccache. This can be done using CCACHE_DIR environment variable. More on this in ccache manual. This way you will keep having faster builds, and will have everything working until we manage to upgrade ccache.

I think I meet a similar situation.
When I execute idf.py gdbgui , there is a red error line shown as below

obviously the t in .espressiftoolsxtensa. was represented as a «TAB»

The red line scared me, but the gdbgui still works fine, I think it is just wrong in the error message, perhaps the internal function is not wrong

Источник

I had a very long path, and there’s a file in there somewhere (not gcc.exe) but another file, that gcc.exe is accessing from the path..

So when I cleared the path, it worked

C:MinGW>cd bin


C:MinGWbin>where gcc.exe
C:MinGWbingcc.exe
C:Perl64sitebingcc.exe

^^ So running gcc from there will definitely run the ming gcc.exe

C:MinGWbin>type file6.c
#include<stdio.h>
void main()
{
int num1,num2;
scanf("%2d %4d",&num1,&num2);
printf("a=%d b=%d",num1,num2);
scanf("%d",&num1);
//flushall();
printf("c=%d",num1);
}

Compiling it I got this error

C:MinGWbin>gcc file6.c
gcc: error: CreateProcess: No such file or directory

My PATH was huge

C:MinGWbin>path
PATH=C:Windowssystem32;C:Windows;C:Windowssystem32wbem;C:P......

C:MinGWbin>path | grep -io «ming»

It didn’t have ming there.

C:MinGWbin>echo MING | grep -io «ming»
MING

(and yeah that grep works..the path didn’t have ming there)

Clearing my path completely, led it to work!

C:MinGWbin>set PATH=

C:MinGWbin>gcc file6.c

C:MinGWbin>

So, it’s not clear yet precisely what it was in the PATH that led to the clash. What directory, what file.

Update-

The above seems to be correct to me but to add, it’s also not a simple case of something earlier in the path clashing.. because normally the current directory takes precedence. And it does here in so far as gcc —version shows it’s running the ming one and not one of the ones in a conflicting directory. So there’s something funny going on that, if the conflicting directory is in the path) , one has to either do .gcc or add . to the start of the path or add c:MinGWbin before any conflicting directories in the path. this is the case even when you’re in C:MinGWbin and that’s strange. And when it gives an error, it is still running Ming’s gcc but (For some reason) looking at the conflicting directory too, as I see from process monitor. There may be more of an answer here http://wiki.codeblocks.org/index.php?title=Installing_MinGW_with_Vista in the link mentioned in the very upvoted answer here

That’s Ming32 bit..

Looking at Ming 64bit, probably has te same issue, but I see, interestingly, it comes with a bat file that (sensibly) actually puts the bin directory at the tart of the path. And it looks like that is a standard way of running Ming gcc properly.

The code::blocks IDE (sensibly) also puts the bin directory at the start of the path. If you run a C program that shows environment variables then you see that.