Spaces in path still cause problems with g++

Hi there,

I am running VS code with PIO and the STSTM32 extension. My home directory unfortunately contains a space and the same is true for my project directory. Strangely, I had no issues with this setup with other projects but now the spaces clearly cause errors. I am on VS Code 1.52.1 and PIO Core 5.0.4, Home 3.3.1

Other threads suggest to install more recent versions of PIO but since they are several years old already I figured this does not apply here. Following a suggestion from another thread, I ran pio run -v and observed the following output:

Processing bluepill (platform: ststm32@10.0.1; board: bluepill_f103c8; framework: libopencm3; board_build.ldscript: stm32f103c8.ld; monitor_speed: 115200; monitor_port: COM4; monitor_flags: --raw; debug_load_mode: modified; lib_archive: False; build_flags: -I include -D LN_TX_ECHO=0 -Wl,-Map,${BUILD_DIR}/ -Wall -Wextra -pedantic -lc; lib_deps:,,,

PLATFORM: ST STM32 (10.0.1) > BluePill F103C8
HARDWARE: STM32F103C8T6 72MHz, 20KB RAM, 64KB Flash
DEBUG: Current (stlink) External (blackmagic, cmsis-dap, jlink, stlink)
 - framework-libopencm3 1.10000.200730 (1.0.0)
 - toolchain-gccarmnoneeabi 1.70201.0 (7.2.1)
LDF: Library Dependency Finder ->
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 7 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <RR32CanLibrary> 0.2.1+sha.4f6b2d2 [git+] (C:\Users\Hans Dampf\3 Projects\Code\c6021light-1.4\c6021light\.pio\libdeps\bluepill\RR32CanLibrary)
|-- <LocoNet> 1.1.4+sha.6b11f7b [git+] (C:\Users\Hans Dampf\3 Projects\Code\c6021light-1.4\c6021light\.pio\libdeps\bluepill\LocoNet)
|   |-- <freertos> (C:\Users\Hans Dampf\3 Projects\Code\c6021light-1.4\c6021light\lib\freertos)
|-- <AtomicRingBuffer> 0.0.1+sha.36ed93e [git+] (C:\Users\Hans Dampf\3 Projects\Code\c6021light-1.4\c6021light\.pio\libdeps\bluepill\AtomicRingBuffer)
|-- <FlashFairyPP> 0.0.1+sha.ed101d7 [git+] (C:\Users\Hans Dampf\3 Projects\Code\c6021light-1.4\c6021light\.pio\libdeps\bluepill\FlashFairyPP)
|-- <microrl> (C:\Users\Hans Dampf\3 Projects\Code\c6021light-1.4\c6021light\lib\microrl)
|-- <freertossupport> (C:\Users\Hans Dampf\3 Projects\Code\c6021light-1.4\c6021light\lib\freertossupport)
|   |-- <freertos> (C:\Users\Hans Dampf\3 Projects\Code\c6021light-1.4\c6021light\lib\freertos)
|-- <freertos> (C:\Users\Hans Dampf\3 Projects\Code\c6021light-1.4\c6021light\lib\freertos)
Building in release mode
arm-none-eabi-g++ -o .pio\build\bluepill\firmware.elf -T stm32f103c8.ld -Wl,-Map,C:\Users\Hans Dampf\3 Projects\Code\c6021light-1.4\c6021light\.pio\build\bluepill/ -Os -Wl,--gc-sections -mthumb -mcpu=cortex-m3 -nostartfiles --static --specs=nano.specs --specs=nosys.specs .pio\build\bluepill\lib0cf\RR32CanLibrary\lib\RR32CanEngineDb\LocoConsumer.o .pio\build\bluepill\lib0cf\RR32CanLibrary\lib\RR32CanEngineDb\LocoListConsumer.o .pio\build\bluepill\lib0cf\RR32CanLibrary\lib\RR32CanEngineDb\util\BufferManager.o .pio\build\bluepill\lib0cf\RR32CanLibrary\lib\RR32CanEngineDb\util\ConfigDataStreamParser.o .pio\build\bluepill\lib0cf\RR32CanLibrary\lib\RR32CanEngineDb\util\Crc.o .pio\build\bluepill\lib0cf\RR32CanLibrary\lib\RR32CanEngineDb\util\TextParser.o .pio\build\bluepill\lib0cf\RR32CanLibrary\lib\RR32Can\Constants.o .pio\build\bluepill\lib0cf\RR32CanLibrary\lib\RR32Can\Locomotive.o .pio\build\bluepill\lib0cf\RR32CanLibrary\lib\RR32Can\RR32Can.o .pio\build\bluepill\lib0cf\RR32CanLibrary\lib\RR32Can\Station.o .pio\build\bluepill\lib0cf\RR32CanLibrary\lib\RR32Can\Types.o .pio\build\bluepill\lib0cf\RR32CanLibrary\lib\RR32Can\messages\Data.o .pio\build\bluepill\lib0cf\RR32CanLibrary\lib\RR32Can\messages\Identifier.o .pio\build\bluepill\lib0cf\RR32CanLibrary\lib\RR32Can\messages\TurnoutPacket.o .pio\build\bluepill\lib0cf\RR32CanLibrary\lib\RR32Can\util\utils.o .pio\build\bluepill\lib9e4\freertos\croutine.o .pio\build\bluepill\lib9e4\freertos\event_groups.o .pio\build\bluepill\lib9e4\freertos\list.o .pio\build\bluepill\lib9e4\freertos\port.o .pio\build\bluepill\lib9e4\freertos\queue.o .pio\build\bluepill\lib9e4\freertos\stream_buffer.o .pio\build\bluepill\lib9e4\freertos\tasks.o .pio\build\bluepill\lib9e4\freertos\timers.o .pio\build\bluepill\lib8cc\LocoNet\LocoNet.o .pio\build\bluepill\lib8cc\LocoNet\utility\ln_buf.o .pio\build\bluepill\lib8cc\LocoNet\utility\ln_sw_uart.o .pio\build\bluepill\lib8cc\LocoNet\utility\utils.o .pio\build\bluepill\libf50\AtomicRingBuffer\AtomicRingBuffer\AtomicRingBuffer.o .pio\build\bluepill\libf50\AtomicRingBuffer\AtomicRingBuffer\StringCopyHelper.o .pio\build\bluepill\lib954\FlashFairyPP\lib\FlashFairyPP\FlashFairyPP.o .pio\build\bluepill\libe7c\microrl\microrl.o .pio\build\bluepill\src\ConsoleManager.o .pio\build\bluepill\src\MarklinI2C\Messages\AccessoryMsg.o .pio\build\bluepill\src\StationCbk.o .pio\build\bluepill\src\WProgram.o .pio\build\bluepill\src\hal\LibOpencm3Hal.o .pio\build\bluepill\src\hal\stm32I2C.o .pio\build\bluepill\src\hal\stm32can.o .pio\build\bluepill\src\hal\stm32eepromEmulation.o .pio\build\bluepill\src\hal\stm32usart.o .pio\build\bluepill\src\main.o .pio\build\bluepill\src\tasks\ConsoleTask\ConsoleTask.o .pio\build\bluepill\src\tasks\RoutingTask\RoutingTask.o -LC:\.pio\platforms\ststm32\ldscripts -L.pio\build\bluepill -LC:\.pio\packages\framework-libopencm3\lib -Wl,--start-group -lc -lc -lgcc -lm -lstdc++ -lnosys .pio\build\bluepill\libFrameworkLibOpenCM3.a -Wl,--end-group
arm-none-eabi-g++: error: Dampf\3: No such file or directory
arm-none-eabi-g++: error: Projects\Code\c6021light-1.4\c6021light\.pio\build\bluepill/ No such file or directory
*** [.pio\build\bluepill\firmware.elf] Error 1
=============================================================================================================================================================================== [FAILED] Took 1.48 seconds ===============================================================================================================================================================================

Any idea what I can do to fix this? I honestly do not understand how these commands are internally assembled and could be influenced.

Thanks in advance.

Can you please show the platformio.ini of the project? The only problem is that in the final linker command

this .map file generation directive doesn’t quote the path correctly.

And since I don’t see a command for that in the main builder code, this error might be user-induced, per platformio.ini build_flag directions, or an extra_scripts direction.

Thanks a lot, your suggestion definitely goes into the right direction. Here is the original platform.ini:

; PlatformIO Project Configuration File
;   Build options: build flags, source filter
;   Upload options: custom upload port, speed and extra flags
;   Library options: dependencies, extra library storages
;   Advanced options: extra scripting
; Please visit documentation for the other options and examples

;default_envs = bluepill
core_dir = C:\\.pio

lib_deps =
build_flags = -I include -D LN_TX_ECHO=0 -Wl,-Map,${BUILD_DIR}/ -Wall -Wextra -pedantic

platform = ststm32@10.0.1
board = bluepill_f103c8
framework = libopencm3

board_build.ldscript = stm32f103c8.ld

monitor_speed = 115200
monitor_port = COM4
monitor_flags = --raw
;upload_port = COM15
debug_load_mode = modified

lib_archive = no
build_flags = ${env.build_flags} -lc
lib_deps = 

I added the core_dir directive as suggested here in a similar thread. Now, after chaning the build_flags line to

build_flags = -I include -D LN_TX_ECHO=0 -Wl,-Map,${BUILD_DIR}\ -Wall -Wextra -pedantic

I realized that I probably have to escape the the backslash as it is otherwise ignored. So

build_flags = -I include -D LN_TX_ECHO=0 -Wl,-Map,${BUILD_DIR}\\ -Wall -Wextra -pedantic

advanced the build process further but I think there still is a problem related to spaces:

arm-none-eabi-gcc -o .pio\build\bluepill\FrameworkLibOpenCM3\lib\cm3\assert.o -c -Wimplicit-function-declaration -Wmissing-prototypes -Wstrict-prototypes -Wall -Wextra -pedantic -Os -ffunction-sections -fdata-sections -Wall -Wextra -Wredundant-decls -Wshadow -fno-common -mthumb -mcpu=cortex-m3 -DPLATFORMIO=50004 -DSTM32F1 -DSTM32F103xB -DARDUINO_BLUEPILL_F103C8 -DLN_TX_ECHO=0 -DF_CPU=72000000L -Iinclude -IC:\.pio\packages\framework-libopencm3 -IC:\.pio\packages\framework-libopencm3\include C:\.pio\packages\frameworarm-none-eabi-g++: error: Dampf\3: No such file or directory
k-liarm-none-eabi-g++: error: Projects\Code\c6021light-1.4\c6021light\.pio\build\bluepill\ No such file or directory

Somehow paths are still strangely split, and I guess the problem is that this file is never generated in the first place (as a consequence).

Just quote that path.


Edit: Since the execution is also relative to the project’s folder, one can also simplify it to -Wl,-Map,, then the file will be in the project’s folder, or something like Wl,-Map,.pio/build/bluepill/, for that specific environment.

Edit 2: Added escaped quoting with \" that actually works, see below.

That unfortunately did not work, but this

did the trick! (Both variants).

For the qouted path I still get similar errors:

arm-none-eabi-g++: error: Dampf\3: No such file or directory
arm-none-eabi-g++: error: Projects\Code\c6021light-1.4\c6021light\.pio\build\bluepill\ No such file or directory
*** [.pio\build\bluepill\firmware.elf] Error 1

I guess the first error causes the second one, but the first one does not really tell what it is looking for?
Edit: Or does it still split the path to and interprets it as two commands? I am a bit puzzled about the missing file error, my understanding is this file is supposed to be created during the build process?
Thanks a lot for your help!

The problem when there’s an unquoted space in the argument list is that it acts like just another argument and thus it thinks it’s another object file that needs to be linked into the final elf. As in

arm-none-eabi-gcc -o firmware.elf -Wl,-Map,"project folder\" obj1.o obj2.o

should mean "write .map file to project folder\, link obj1.o obj2.o, but without the quotes

arm-none-eabi-gcc -o firmware.elf -Wl,-Map,project folder\ obj1.o obj2.o

it looks like the map file is supposed to go in project and folder\ obj1.o obj2.o are the to-be-linked object files. The more spaces the more wrong object files it tries to link. Obviously it would fail when opening these object file paths for linkage.

Hm but somehow this didn’t work out. Maybe it needs an escaped -Wl,-Map,\"${BUILD_DIR}\\" or something. But if the last two work I guess it’s okay :smiley:

Also, the .map file is not critical for the firmware to run. It’s just a map of which symbol (variable, function) has which size and address within the final firmware. That directive can be entirely deleted if you don’t care about that for post-analysis.

1 Like

Thanks for the explanation, that makes a lot of sense.

Jackpot! The escpaed quote is what was needed. I will mark your other reply above as solution, maybe you want to edit that in.

Thanks a ton for sorting this out, this was a very cool community experience!

1 Like