Build issue with --wrap=realloc after latest update (6.1.13)

Hi everyone,

I have been tinkering for the last two days with an issue: I had the issue that we use tkinter in extra_scripts which was apparently not included in the latest shipped-with python version (despite deleting penv and python3 folders as recommended in the changelog) - however, I solved this by using my global python installation instead, which includes tkinter by default, as written here.

Interestingly, an (probably unrelated issue) also occurred: When using either the built-in python (but not tkinter-scripts) or global python, linking ends with the following error:

.pio\build\sensotronic2\libFrameworkArduino.a(WString.cpp.o): In function `String::String(char const*)':
WString.cpp:(.text._ZN6StringC2EPKc+0x1c): undefined reference to `__wrap_realloc'
collect2.exe: error: ld returned 1 exit status
*** [.pio\build\sensotronic2\firmware.elf] Error 1

I tried the same procedures on other PCs who did NOT have this issue. I also tried clean-reinstalling VSCode, all extensions including platformio IDE, and C:/.platformio folders, re-cloning the project from git etc. to no success. I then noticed that I had the “GNU Arm Embedded Toolchain” toolchain installed (independently of the automatically downloaded one which comes with the used platform? in .platformio/toolchain-gccarmnoneeabi folder). Uninstalling this + removing PATH variables etc. also did not lead to a solution and was previously also not causing any issues.

At this point, I am kind of running out of options since the behavior is not reproducible on other PCs (Windows machines with same OS version that I have) but potentially one of you has an idea what the reason for this could be.

System: Windows 11 Pro 10.0.22621 Build 22621.


default_envs = sensotronic2
;default_envs = config_writer_s2
;default_envs = unit_test_s2

platform = nordicnrf52
debug_tool = jlink
upload_protocol = jlink
board_build.filesystem = littlefs
board_build.variants_dir = sensotronic_variants
framework = arduino
monitor_speed = 115200
monitor_filters = send_on_enter
monitor_echo = yes
;build_type = debug ;disable optimizations for debugging
lib_deps = 
	adafruit/Adafruit SPIFlash@^4.0.0^1.3.1^1.1.1

platform_packages = 

board = adafruit_feather_nrf52840
build_src_filter = +<*> -<.git/> -<.svn/> -<config/write_config.cpp>
build_flags = 
	-DSPI_32MHZ_INTERFACE=1 ; this forces SPIM2 (instead of 3) and avoids this bug:

lib_deps = 
extra_scripts = 

The issue seems to be related to this line in the framework’s platform.txt for compiler ld-flags:

compiler.ldflags=-mcpu={build.mcu} -mthumb {build.float_flags} -Wl,--cref -Wl,--check-sections -Wl,--gc-sections -Wl,--unresolved-symbols=report-all -Wl,--warn-common -Wl,--warn-section-align -Wl,--wrap=malloc -Wl,--wrap=free -Wl,--wrap=realloc -Wl,--wrap=calloc --specs=nano.specs --specs=nosys.specs

Dangerous. This instructs PlatformIO to grab the latest stable nordicnrf52 platform version (if not installed, otherwise possibly older previously installed version will be used) and also the very latest version of the framework-arduinoadafruitnrf52 package (registry). It could be possible to get a missmatch between those versions.

Can you please try the following:

  1. Remove platform_packages = framework-arduinoadafruitnrf52.
  2. Try with with platform = nordicnrf52@10.3.0
  3. If not successfull, try with platform = nordicnrf52@10.2.0

You are incredible!

This is/was indeed the issue. Reverting to platform = nordicnrf52@10.2.0 did the trick.

I guess me fiddling with the .platformio installs due to my python lib issues caused to update the locally cached platform dependency and updated the nordicnrf52 to 10.3.0 (Release 10.3.0 · platformio/platform-nordicnrf52 · GitHub)? This specifically mentions that the downgraded the GCC toolchain to v7 around 3 weeks ago.

I guess another reason to use fixed versioning instead of relying on “stable/non-breaking” updates.

  • I guess my colleagues could face a similar issue once something triggers their platform dependy update. I may want to investigate / raise an issue with the maintainer of the framework-arduinoadafruitnrf52 to keep compatibility up-to-date with the latest nordicnrf52 framework.

Thanks so much once again!

P.S.: I could reproduce the same issue and solution on a colleague’s PC by manually deleting the cached nordicnrf platform.

PS2.: I also found the framework’s incompatible wrap realloc-introduction Implemented thread-safe realloc and calloc by godario · Pull Request #744 · adafruit/Adafruit_nRF52_Arduino · GitHub

PS3: Raised an issue in the platform with possible workarounds on the platform’s side to restore compatibility with the latest framework release: Bug: Reintroduction of old GCC toolchain as optional version breaks adafruit arduino framework using ld's --wrap=realloc · Issue #191 · platformio/platform-nordicnrf52 · GitHub

EDIT final source of the problem: my own framework fork was not up to date (on v1.5.0 instead of 1.6.0) while the most recent platform version (10.3.0) required it to be. So the accepted solution is just a workaround for an outdated framework version and ONLY required if this framework is pulled in a custom manner.

Does this error occur in a clean

platform = nordicnrf52@10.2.0
board = adafruit_feather_nrf52840
framework = arduino


platform = nordicnrf52@10.3.0
board = adafruit_feather_nrf52840
framework = arduino

? I would be baffled if it does, the stable releases should work. Only when you force a platform to work with a older or newer framework package than it’s designed for, with platform_packages, it should break, which is then also kind of expected.

Sorry for the delay. You are, of course, correct. The underlying issue was - as you suggested - due to our own framework fork (which we kinda rely on due to the irregular release schedule and some custom modifications). Apparently I had the impression this was not the case, since the same build issue came up when removing the “@” after platform_packages = framework-arduinoadafruitnrf52, which apparently did not trigger a cache refresh of the downloaded platform package (and thereby did not pull the offical repo).

It turns out, that our fork was out of sync with the official upstream, which apparently confused the build system, leading to the probably “expected breaking”.

Overall, it works fine but the lession of me remains the same. Keep static versions of everything. Thank you so much again!