# 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}/firmware.map -Wall -Wextra -pedantic -lc; lib_deps: https://github.com/deltaphi/RR32CanLibrary.git#4f6b2d293c86135731f2493ed56fc42a39ec6b87, https://github.com/deltaphi/LocoNet#6b11f7b36549baca259b12d5282dc6d75443d5a3, https://github.com/deltaphi/AtomicRingBuffer#36ed93eb58c0c4a0fc8ddc8d19a7f48588e334db, https://github.com/deltaphi/FlashFairyPP#ed101d7561945f8cdd034506f4f12f06241f7aec) ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/bluepill_f103c8.html PLATFORM: ST STM32 (10.0.1) > BluePill F103C8 HARDWARE: STM32F103C8T6 72MHz, 20KB RAM, 64KB Flash DEBUG: Current (stlink) External (blackmagic, cmsis-dap, jlink, stlink) PACKAGES: - framework-libopencm3 1.10000.200730 (1.0.0) - toolchain-gccarmnoneeabi 1.70201.0 (7.2.1) LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf LDF Modes: Finder ~ chain, Compatibility ~ soft Found 7 compatible libraries Scanning dependencies... Dependency Graph |-- <RR32CanLibrary> 0.2.1+sha.4f6b2d2 [git+https://github.com/deltaphi/RR32CanLibrary.git#4f6b2d293c86135731f2493ed56fc42a39ec6b87] (C:\Users\Hans Dampf\3 Projects\Code\c6021light-1.4\c6021light\.pio\libdeps\bluepill\RR32CanLibrary) |-- <LocoNet> 1.1.4+sha.6b11f7b [git+https://github.com/deltaphi/LocoNet#6b11f7b36549baca259b12d5282dc6d75443d5a3] (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+https://github.com/deltaphi/AtomicRingBuffer#36ed93eb58c0c4a0fc8ddc8d19a7f48588e334db] (C:\Users\Hans Dampf\3 Projects\Code\c6021light-1.4\c6021light\.pio\libdeps\bluepill\AtomicRingBuffer) |-- <FlashFairyPP> 0.0.1+sha.ed101d7 [git+https://github.com/deltaphi/FlashFairyPP#ed101d7561945f8cdd034506f4f12f06241f7aec] (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/firmware.map -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/firmware.map: 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 ; https://docs.platformio.org/page/projectconf.html [platformio] ;default_envs = bluepill core_dir = C:\\.pio [env] lib_deps = https://github.com/deltaphi/RR32CanLibrary.git#4f6b2d293c86135731f2493ed56fc42a39ec6b87 https://github.com/deltaphi/LocoNet#6b11f7b36549baca259b12d5282dc6d75443d5a3 https://github.com/deltaphi/AtomicRingBuffer#36ed93eb58c0c4a0fc8ddc8d19a7f48588e334db https://github.com/deltaphi/FlashFairyPP#ed101d7561945f8cdd034506f4f12f06241f7aec build_flags = -I include -D LN_TX_ECHO=0 -Wl,-Map,${BUILD_DIR}/firmware.map -Wall -Wextra -pedantic

[env: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

lib_archive = no
build_flags = ${env.build_flags} -lc lib_deps =${env.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}\firmware.map -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}\\firmware.map -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\firmware.map: No such file or directory
bopencm3\lib\cm3\assert.c


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

Just quote that path.

-Wl,-Map,\"${BUILD_DIR}\firmware.map\"  Edit: Since the execution is also relative to the project’s folder, one can also simplify it to -Wl,-Map,firmware.map, then the file will be in the project’s folder, or something like Wl,-Map,.pio/build/bluepill/firmware.map, 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\firmware.map: 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 firmware.map 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\firmware.map" obj1.o obj2.o  should mean "write .map file to project folder\firmware.map, link obj1.o obj2.o, but without the quotes arm-none-eabi-gcc -o firmware.elf -Wl,-Map,project folder\firmware.map obj1.o obj2.o  it looks like the map file is supposed to go in project and folder\firmware.map 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}\firmware.map\" or something. But if the last two work I guess it’s okay

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