Raspberry Pi 5 VSCode Compile Error

[KPrivitt]

I am not a platformio.ini expert, but I found that I could not compile the MeshCore firmware on my new Raspberry Pi OS based system using VSCode. The Raspberry Pi uses an ARM core processor. I do not have any issues with my Windows 11 Intel CPU based system.

I received this error:
Tool Manager: Installing platformio/toolchain-gccarmnoneeabi @ >=1.60301.0,<1.80000.0
UnknownPackageError: Could not find the package with 'platformio/toolchain-gccarmnoneeabi @ >=1.60301.0,<1.80000.0' requirements

I searched for this and I could not find it in the Git Hub code base, so I was not sure why it is loading this. The only place I found that "toolchain" existed was in a comment and not in the code.

It turns out this is an older version that is apparently no longer available and that is why it could not be found.

The solution was to add: toolchain-gccarmnoneeabi @ 1.400201.0 to the platformio.ini file.

[nrf52_base]
platform_packages =
toolchain-gccarmnoneeabi @ 1.1400201.0

VSCode then downloaded it and the MeshCore firmware would now compile with no errors.

Should this line be added to the main GitHub MeshCore codes platformio.ini file?

Or do I just need to add this each time to my local copy that I clone to my Raspberry Pi based system.

[KPrivitt]

I did some additional research and found that:
Windows PlatformIO chose GCC 9.x because that’s the default toolchain bundled with the nordicnrf52 platform (I'm not sure where this is...) on the Windows version.

Raspberry Pi’s PlatformIO tries to install toolchain-gccarmnoneeabi @ >=1.60301.0,<1.80000.0
That version range no longer exists in the registry
PlatformIO on ARM Linux simply does not ship the GCC 9.x toolchain anymore.

Both are "compatible" with MeshCore code, but I found one incompatibility with my code:

time_t is now undefined.

This is because GCC 14.x:

Implements C++20 and large parts of C++23.
Much stricter header hygiene.
Requires explicit includes for:
<cstdint>
<cstring>
<cstdlib>
<time.h> (your case)
More aggressive constexpr evaluation.
More aggressive dead‑code elimination.

If MeshCore explicitly adds the GCC 14.x toolchain it will be compatible with both versions of VSCode.

But it will expose the existing code to the new restrictions (which from a coding perspective is probably a good thing, but I introduced the incompatibility by using time_t, from a cut and paste, I used uint32_t everywhere else. I never found it because it compiled with no errors.)

I can fix my RAK12035_Soilmoisture.cpp (which used time_t) by changing it to uint32_t or adding by <time.h> to RAK12035_Soilmoisture.h

My code is fully compatible with the existing toolchain and can be corrected for future compatibility. Which fix would you prefer? One of the two above, or leave it as is.

Would the devs consider moving to the new toolchain?

[jirogit]

Thanks for the thorough investigation!

Just sharing a personal perspective (I'm a contributor, not a maintainer):

On the toolchain pin PR: Building on Raspberry Pi (ARM Linux) isn't an explicitly supported build environment for MeshCore, so maintainers may be hesitant to accept a toolchain version pin that they can't easily test or maintain. Your local workaround is probably the most pragmatic path for now.

On GCC 14.x migration: A dedicated migration branch is probably overkill at MeshCore's current scale. The more typical approach here would be fixing strict-header issues individually as they're discovered — which is exactly what you're already doing with the time_t → uint32_t change.

On your specific fix: I grepped the codebase for time_t usage and found only 3 occurrences total. Two are legitimate POSIX API boundaries (gmtime() in RTC_RX8130CE.cpp, time() in ESP32Board.h) where time_t is required by the function signature. The only problematic usage is the one you already identified — RAK12035_SoilMoisture.cpp:434 where millis() result is stored in time_t. Changing that to uint32_t is the right fix, and the scope is small.

Hope that helps set expectations. The maintainers will have the final word on whether a platformio.ini change makes sense upstream.

[KPrivitt]

I have submitted a PR to change time_t to uint32_t in RAK12035_SoilMoisture.cpp:434
While not technically necessary, this future proofs the code by eliminating the use of time_t entirely.

I am not closing this yet; I would like to hear from the maintainers' on their position with GCC 14.x