log_printf wrapping in build flags

[Jason2866]

Description:

Related issue (if applicable): fixes #495

Checklist:

• The pull request is done against the latest develop branch
• Only relevant files were touched
• Only one feature/fix was added per PR, more changes are allowed when changing boards.json
• I accept the CLA

[Jason2866]

@coderabbitai Analyze if the PR fix #495

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

@Jason2866 — Yes, PR #497 correctly fixes issue #495. Here is the detailed analysis:

---

Issue #495 — Root Cause Recap

When a user sets custom_sdkconfig, PlatformIO enters hybrid compile mode and rebuilds esp_diagnostics from source. In that rebuilt library, __wrap_log_printf is not compiled in because the symbol is gated behind #ifdef CONFIG_LIB_BUILDER_COMPILE — a flag injected only by Espressif's internal CI, not a real Kconfig option that survives into sdkconfig.h.

Meanwhile, pioarduino-build.py (generated per-target) unconditionally adds -Wl,--wrap=log_printf to LINKFLAGS. The result is an orphan wrap flag → linker error:

undefined reference to `__wrap_log_printf'

---

What PR #497 Does

In builder/frameworks/arduino.py (the Arduino framework builder, which covers hybrid compile for all targets — ESP32-S3, ESP32, etc.), it unconditionally appends the flag to build_unflags:

# -Wl,--wrap=log_printf: remove always. Diagnostics is not supported with HybridCompile
build_unflags += " -Wl,--wrap=log_printf"

This strips the orphan flag before the linker runs, regardless of target or custom_sdkconfig content.

---

Assessment

Criterion	Result
Directly removes the offending flag in hybrid compile path	✅
Covers all targets (shared arduino.py)	✅
Matches maintainer's stated intent (always remove in hybrid mode)	✅
Functionally equivalent to the documented workaround (build_unflags = -Wl,--wrap=log_printf) but automatic	✅
Trade-off: esp_diagnostics log interception disabled in hybrid compile	✅ Acceptable — it never worked there anyway

The fix is clean, minimal, and targets the exact code path where the problem manifests. It correctly implements the "hardcore fix" you described in the issue comments.