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.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Projects which live in a folder path where there is a space, or where we are building for an environment (as defined in th e platformio.ini) that has a space in it, fail to link.
Example: I create a ESP32 project at the path C:\Users\Max\temp\Test Project With Spaces using the platformio.ini
with a semantically empty src/main.cpp code. Linking fails with
Linking .pio\build\esp32dev with spaces\firmware.elf
xtensa-esp32-elf-g++: error: Project: No such file or directory
xtensa-esp32-elf-g++: error: With: No such file or directory
xtensa-esp32-elf-g++: error: Spaces.map: No such file or directory
*** [.pio\build\esp32dev\firmware.elf] Error 1
================[FAILED] Took 102.29 seconds ================
which is due to the linker flag for generating the .map file being
-Wl,-Map="C:\Users\Max\temp\Test Project With "Spaces\.pio\build\esp32dev\Test Project With Spaces.map""
as one can see, unexpectedly before the wor Spaces there is a ". This prematurely ends the string for the -Map= argument, and the command is messed up.
which looks correct, but behind-the-scenes corrections / auto-escaping of anything that has a space done presumably by either SCons or the PlatformIO in it destroys this logic and produces these wrong commands.
A workaround is to use as much relative paths as possible to get only .pio\build\<env name>\<project name>.map, and then remove the spaces if there are any.
I'm opening this bug here so that a temporary fix may be implemented, working around what looks like a core bug to me. Due to the war, fixes on the PlatformIO side may take a very long time.
Sketch
#include<Arduino.h>voidsetup() {}
voidloop(){}
Debug Message
None relevant.
Other Steps to Reproduce
None relevant.
I have checked existing issues, online documentation and the Troubleshooting Guide
I confirm I have checked existing issues, online documentation and Troubleshooting guide.
The text was updated successfully, but these errors were encountered:
Board
any
Device Description
Not relevant.
Hardware Configuration
Not relevant.
Version
latest master
IDE Name
PlatformIO
Operating System
Windows 10 x64
Flash frequency
40
PSRAM enabled
no
Upload speed
115200
Description
Projects which live in a folder path where there is a space, or where we are building for an environment (as defined in th e
platformio.ini
) that has a space in it, fail to link.Example: I create a ESP32 project at the path
C:\Users\Max\temp\Test Project With Spaces
using theplatformio.ini
with a semantically empty
src/main.cpp
code. Linking fails withwhich is due to the linker flag for generating the
.map
file beingas one can see, unexpectedly before the wor
Spaces
there is a"
. This prematurely ends the string for the-Map=
argument, and the command is messed up.The builder script does
arduino-esp32/tools/platformio-build-esp32.py
Line 115 in 0b10c8b
which looks correct, but behind-the-scenes corrections / auto-escaping of anything that has a space done presumably by either SCons or the PlatformIO in it destroys this logic and produces these wrong commands.
A workaround is to use as much relative paths as possible to get only
.pio\build\<env name>\<project name>.map
, and then remove the spaces if there are any.EDIT: A better fix has been found in the linked PR.
As shown in https://community.platformio.org/t/working-with-esp-arduino-2-0-2/26540/6?u=maxgerhardt and following. The person in https://community.platformio.org/t/xtensa-esp32-elf-g-error-controller-map-no-such-file-or-directory/26675 is also affected.
I'm opening this bug here so that a temporary fix may be implemented, working around what looks like a core bug to me. Due to the war, fixes on the PlatformIO side may take a very long time.
Sketch
Debug Message
Other Steps to Reproduce
None relevant.
I have checked existing issues, online documentation and the Troubleshooting Guide
The text was updated successfully, but these errors were encountered: