Issue with mklittlefs in ESP-IDF

[atlaste]

Context:

• This is on Windows.
• I have a clean installation of ESP-IDF (latest) on my machine and a fully upgraded MSYS installation.
• I'm using the joltwallet/esp_littlefs from the managed components of ESP-IDF. That's 1.5.3 per IDF component registry.
• CMakeLists.txt has:

littlefs_create_partition_image(littlefs data)

Behavior:

The behavior is different in IDF powershell, IDF command, and regular CMD.

• In IDF powershell: mklittlefs.exe does absolutely nothing. No crash, no help, no error, just nothing at all.
• In IDF cmd. I get a popup: "The procedure entry point _ZSt28__throw_bad_array_new_lengthv could not be located in the dynamic link library C:[...]\mklittlefs.exe."
• In a normal cmd I get the help and the tool appears to do what it's supposed to do.

What I've tried:

The popup appears to be related to the wrong SO being loaded. I'm unfortunately not really custom to the GCC toolchain, but nonetheless:

• Use the zipped executable first (obviously). No luck there.
• Make clean, make dist, etc. Doesn't appear to solve anything. It gives an error while stripping the symbols out, but seems fine otherwise.
• According to some googl'ing the CC/GCC executable appeared to be the culprit. Here it made no difference.
• According to some googl'ing the -static -static-libgcc -static-libstdc++ flags might blow up in your face as described above. Again, no difference here.

I'm starting to get a bit fresh out of ideas here. Perhaps more eyes are needed here.

[atlaste]

Just had a new thought while trying to solve this one step at a time. According to https://stackoverflow.com/questions/74734500/cant-find-entry-point-zst28-throw-bad-array-new-lengthv-in-dll-filepath - the order of items in the path is relevant. So I moved msys to the top, and that seems to do something: the executable seems to work now. Still weird though, the whole idea of static compilation is of course that this isn't needed...

Unfortunately the path gets overwritten by the IDF initialization script...

Correct:

ldd .\managed_components\joltwallet__littlefs\mklittlefs\mklittlefs.exe [...] libstdc++-6.dll => /mingw64/bin/libstdc++-6.dll (0x7fff909f0000) libgcc_s_seh-1.dll => /mingw64/bin/libgcc_s_seh-1.dll (0x7fffd3530000) libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll (0x7fffcc6f0000) libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll (0x1b639230000)

Incorrect:

PS C:\Projects\CNC\Accelerometer\Accelerometer> ldd .\managed_components\joltwallet__littlefs\mklittlefs\mklittlefs.exe [...] libstdc++-6.dll => /c/Espressif/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/libstdc++-6.dll (0x57970000) USER32.dll => /c/WINDOWS/System32/USER32.dll (0x7fffdfa30000) libgcc_s_seh-1.dll => /c/Espressif/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/libgcc_s_seh-1.dll (0x58820000) [...]

After further inspection, I found a bug in the Makefile:

    TARGET_OS := win32

...

ifeq ($(TARGET_OS),windows)

After changing win32 to windows, ldd seemed to be happy, and so is PowerShell,

[BrianPugh]

Thanks for opening an issue!

fix seems to be what @eldendiss mentioned in #102. Closing this issue in favor of #102. Will close #102 once changes are merged.