PlatformIO Community

Linker fails after PlatformIO update ESP32

I have been working on a project for the last 4 months and had no problem compiling and linking it using the PlatformIO IDE. The project is ESP32 based. Last Monday, I compiled a version in the STAGGING environment. On Friday I recompiled in the RESEARCH environment, which is identical but with a different #define. It failed in the linker with the messages:

Linking .pio\build\esp-wrover-kit-Jlink-RESEARCH\bootloader.elf
/bin/ld.exe: \main\libmain.a(bootloader_start.c.o):(.literal.selected_boot_partition+0x0): undefined reference to bootloader_utility_get_selected_boot_partition' /bin/ld.exe: \main\libmain.a(bootloader_start.c.o):(.literal.selected_boot_partition+0x4): undefined reference to bootloader_common_get_reset_reason’
/bin/ld.exe: \main\libmain.a(bootloader_start.c.o):(.literal.select_partition_number+0x8): undefined reference to bootloader_utility_load_partition_table' /bin/ld.exe: \main\libmain.a(bootloader_start.c.o):(.literal.select_partition_number+0xc): undefined reference to esp_log_timestamp’
/bin/ld.exe: \main\libmain.a(bootloader_start.c.o):(.literal.call_start_cpu0+0x0): undefined reference to bootloader_init' /bin/ld.exe: \main\libmain.a(bootloader_start.c.o):(.literal.call_start_cpu0+0x4): undefined reference to bootloader_reset’
/bin/ld.exe: \main\libmain.a(bootloader_start.c.o):(.literal.call_start_cpu0+0xc): undefined reference to bootloader_utility_load_boot_image' /bin/ld.exe: \main\libmain.a(bootloader_start.c.o): in function selected_boot_partition’: \main/bootloader_start.c:75: undefined reference to bootloader_utility_get_selected_boot_partition' /bin/ld.exe: \main/bootloader_start.c:79: undefined reference to bootloader_common_get_reset_reason’
/bin/ld.exe: \main\libmain.a(bootloader_start.c.o): in function select_partition_number': \main/bootloader_start.c:60: undefined reference to bootloader_utility_load_partition_table’
/bin/ld.exe: \main/bootloader_start.c:67: undefined reference to esp_log_timestamp' /bin/ld.exe: \main\libmain.a(bootloader_start.c.o): in function call_start_cpu0’: \main/bootloader_start.c:33: undefined reference to bootloader_init' /bin/ld.exe: \main/bootloader_start.c:34: undefined reference to bootloader_reset’
/bin/ld.exe: \main/bootloader_start.c:53: undefined reference to bootloader_utility_load_boot_image' /bin/ld.exe: \main/bootloader_start.c:53: undefined reference to bootloader_reset’
collect2.exe: error: ld returned 1 exit status
*** [.pio\build\esp-wrover-kit-Jlink-RESEARCH\bootloader.elf] Error 1

I then retried the STAGGING environment and it also failed with the exact same errors. There was no code change between Monday and Friday. I did notice that PlatformIO did update itself. God only knows what was updated. Now nothing works. I went to two different colleagues, who compiled without issues. When one of them did the update, he also developed the linker error. The second colleague did not have this problem, using the same code repo, but he was using a MAC. He then used a Windows 10 computer one which he installed PlatformIO, VSCode and ESP32 2.1.0 platform. He also now can reproduce this error.

Please supply a solution ASAP. We have a very important client who is waiting for the STAGGING version of this code to be released to their field units. # different software engineers on 3 different computers are running into the exact same issue. I understand that we can use the MAC to generate the client version, but we need a Windows solution.

Ok, I figured out it broke when it updated to 5.2.4.
I NEED to downgrade to 5.2.2 and kill the auto updates. Please respond to this

Additional details… in our platformio.ini we are using:

platform = espressif32@2.1.0

So as an experiment, I created a new empty project with the above et viola – it fails in the same way we’re seeing. So the reproducible test case is as simple as:

[env:esp-wrover-kit]
platform = espressif32@2.1.0
board = esp-wrover-kit
framework = espidf

and a 1 line main.c:

void app_main() {}

Sorry, one more thing – failure only happens on Windows. MacOS and Linux seem to be fine.

¯_(ツ)_/¯

For professional support on this topic you should open a ticket at https://platformio.org/support.

I am running into the same issue, together with another co.-worker. Can you please give feedback on that issue? We are using espressif32@2.1.0 and cannot migrate to a higher version!

Open an issue at https://github.com/platformio/platform-espressif32/ with the exact error message and platformio.ini configuration, have them uphold backwards compatibility.

How is this an issue of platform-espressif32? We did not change the version here, it seems that cores are the issue. Code was not changed at all, just fails after auto-update of the cores. It is not possible to downgrade.

K, then open one at https://github.com/platformio/platformio-core/issues

Yes it is, you can always manually activate the penv that PlatformIO is installed in and do a pip-uninstall of the old PlatformIO core and a pip-install of a fixed version of the core.

Assuming Linux paths:

# for linux
cd ~/.platformio
source ./bin/activate
pip uninstall platformio
pip install "platformio==5.1.1"

see platformio · PyPI.

Of course you should disable auto-update in the PlatformIO VSCode extension settings then too.

Also see Lib not found with last versión Core change? Home change? Framework? - #2 by maxgerhardt.

Good morning trichl,
We have done extensive work to solve this issue and this is the meat of it:

  • This issue is not present if you compile using a MAC or a Linux VM
  • I have wipe clean my computer, include the registry, and re-install 5.2.3 of PIO but the problem remained

I have traced the problem to the LDF.exe library dependency builder tool. Apparently, it has issues with the path of one of the 2.1.0 library which embeds include header libs in this fashion:
#include <lib\blabla.h>
and it can’t figure out where to look for the header file. The problem with rolling back the core is that it does not roll back the LDF.exe tool since it is provided by Extensa. So after many hours (days) of looking for a solution, I gave up and we decided to migrate the Espressif libs to 3.4.0. To our surprise, the project compiled right up and after extensive testing by us and by our client, there are no issues.

Hope this helps

Still, if you have a reproducable project on Windows for ESP-IDF that fails on a newer core version but works with a lower core version, please open an issue in the core.

Thanks for your update. I could finally workaround the issue, that’s what worked on Windows:

In the VS Code PlatformIO Terminal: pip install “platformio==5.1.1”, like maxgerhardt suggested (thanks a lot). Other downgrades didn’t work. Then restarting VS Code and it worked again.