Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

`libmicroros.a` is built with a hand-maintained toolchain file that may drift from IDF's compile flags (ABI mismatch risk)

Open
  • Is something wrong?
#373 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
c, cmake
Domain
build-system, embedded-iot

Research direction

Start with esp32_toolchain.cmake.in, libmicroros.mk, and the outer CMakeLists.txt to trace how IDF compile flags reach the separate colcon build. Compare the flags used by IDF components with those passed to libmicroros.a, focusing on RISC-V ABI and PSRAM options. Done means the sub-build receives the relevant flags without a manually drifting list, or the unsynchronized flags are explicitly documented.

Written by the indexing model from the issue text.

Description

From https://github.com/micro-ROS/micro_ros_espidf_component/pull/334#issuecomment-4829889550

The following content was generated by AI

Cause

micro-ROS is not built as regular IDF component sources. Instead, the component's CMake configure step invokes libmicroros.mk, which runs a separate colcon build to produce libmicroros.a, and the result is linked back into the ELF via add_prebuilt_library. This separate build uses its own toolchain file (esp32_toolchain.cmake.in) that only passes through a hand-picked subset of compile options (compiler binary, C standard, sdkconfig.cmake, IDF includes, a few hardcoded flags), rather than inheriting the full set of flags IDF applies to its own components.

Impact

Some ABI-affecting flags used by the main IDF build are not propagated to the micro-ROS sub-build, so libmicroros.a can be compiled with settings inconsistent with the rest of the firmware. Known gaps:

  • RISC-V -march/-mabi are not set (relies on compiler defaults) — a mismatch here breaks the calling convention/ABI.
  • PSRAM cache workaround flags (e.g. -mfix-esp32-psram-cache-issue) are not forwarded.
  • The hardcoded flag list in esp32_toolchain.cmake.in must be kept in sync manually and can silently drift as IDF changes.

(Note: many flags like optimization level or stack protector are not ABI-breaking, so their absence is harmless — the concern is specifically the ABI/codegen-relevant ones.)

Because the same compiler is used and sdkconfig.cmake is included, most struct-layout / config-dependent mismatches are already avoided, so this is a latent risk rather than a guaranteed failure — but it can produce hard-to-debug link/runtime issues in specific configurations (e.g. SPIRAM enabled, certain RISC-V targets).

Possible fix

Keeping micro-ROS as a separately built static library is unavoidable (it depends on the ROS 2 / colcon / rosidl build system), so the goal is not to remove this mechanism but to make the sub-build inherit IDF's ABI-relevant flags instead of hardcoding a subset:

  • Query the flags IDF actually uses for its components (e.g. CMAKE_C_FLAGS / COMPILE_OPTIONS, especially RISC-V -march/-mabi and PSRAM-related flags) in the outer CMakeLists.txt and pass them through libmicroros.mk into the toolchain file.
  • As a minimum/interim step, document the list of flags that are known not to be synced and must be verified manually.
Dominant language
C
Stars
419
Forks
123
Avg merge
2d 21h
Merged PRs (30d)
1

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from micro-ROS/micro_ros_espidf_component

All issues in micro-ROS/micro_ros_espidf_component

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.