Why PC .c files full path strings are in built Micropython firmware (usermod) ?
Port, board and/or hardware
esp32
MicroPython version
1.26.1
Reproduction
.
Expected behaviour
.
Observed behaviour
I'm upgrading from MPY 1.25 + IDF 5.3 to MPY 1.26.1 + IDF 5.4.2 , for ESP32C3. I built my MPY firmware. Using a lot of custom code in usermod.
Using strings micropython.bin command, I found that newly generated micropython.bin contains many usermod .c file absolute PC path strings:
/onpc/long/path/micropython/ports/esp32/usermod/aa.c
/onpc/long/path/micropython/ports/esp32/usermod/xxxx/gg.c
....
(only usermod .c file paths appeared. Other MPY .c file path not)
Although those PC path strings won't take 200KB, is their being there in firmware is a config bug? (Since MPY 1.26 or since IDF 5.4 ?)
I checked firmware files I built before upgrading (also have usermod). Those path strings were not in old firmwares.
When you have many .c files in usermod, those strings can take tens of KB, which is not good for small-Flash mcu.
Additional Information
I didn't add any debugging or logging flag to build config.
My .cmake in usermod has always be like:
add_library(usermod_xxxx INTERFACE)
target_sources(usermod_xxxx INTERFACE
${CMAKE_CURRENT_LIST_DIR}/xxxx.c
${CMAKE_CURRENT_LIST_DIR}/xxxxx.c
.....
)
target_include_directories(usermod_xxxx INTERFACE
${CMAKE_CURRENT_LIST_DIR}
)
target_link_libraries(usermod INTERFACE usermod_xxxx)
Code of Conduct
Yes, I agree
USER_C_MODULE impossible to import library
Port, board and/or hardware
ESP32S3 (16MB of Flash & Octal-SPIRAM)
MicroPython version
MicroPython v1.26.0-preview.59.g79abdad9e.dirty on 2025-05-04
Build with ESP-IDF 5.4.1 toolchain
Hi, I've been upgraded Micropython to 1.26 and ESP-IDF to 5.4.1 since a bug report in my own repository.
I compile the firmware a usual (it was working with micropython 1.25 and ESP-IDF 5.3.2) without issue, However I cannot import the module as before. (import xxx lead to an ImportError: no module named 'xxx')
The help('modules') command shows usual library but not the one from the User_C_module (before I used to see xxx module)
The build command was
make BOARD=ESP32_GENERIC_S3 BOARD_VARIANT=FLASH_16M_SPIRAM_OCT USER_C_MODULE=~/pico/XXX/xxx
I thought Issue #16424 would have closed the issue but no luck...
I'm not sure it's a bug, but I does look like...
Reproduction
make BOARD=ESP32_GENERIC_S3 BOARD_VARIANT=FLASH_16M_SPIRAM_OCT USER_C_MODULE=~/pico/XXX/xxx
Was working well with Micropython v1.25.0-preview.180.g495ce91ca.dirty on 2025-02-15 & IDF 5.3.2
Was not working with Micropython v1.26.0-preview.59.g79abdad9e.dirty on 2025-02-15 & IDF 5.3.2
So I expect it is not related to IDF version
Expected behaviour
Normal output is
import xxx ==> Nothing (OK)
Observed behaviour
Observed output is
import xxx ==> ImportError: no module named 'xxx'
Additional Information
No, I've provided everything above.
Code of Conduct
Yes, I agree