teensy41 regression in 2.2.4: bundled FastLED from Teensy core/ is compiled alongside local lib → multiple definition errors for every example

[zackees]

Summary

Upgrading from fbuild==2.2.3 to fbuild==2.2.4 causes every teensy41 example to link-fail with multiple definition errors. Each FastLED symbol gets defined twice — once from the local FastLED source the user is building, and once from the bundled FastLED library that ships with Teensyduino under cores/teensy4/.../libraries/FastLED/. 2.2.4 appears to no longer exclude the bundled library from the build set.

This is strictly worse than 2.2.3 for the teensy41 workflow:

• 2.2.3: 1 example (Ports/PJRCSpectrumAnalyzer) failed at link due to missing CMSIS-DSP (teensy41: link fails on Ports/PJRCSpectrumAnalyzer — missing CMSIS-DSP (arm_cortexM7lfsp_math) in link args #257).
• 2.2.4: 64+ examples (essentially all) fail at link due to bundled-FastLED duplication. The CMSIS-DSP fix is now moot because the link can't even get there for any other example.

Symptom

ld: /home/runner/work/FastLED/FastLED/.build/pio/teensy41/.fbuild/build/teensy41/release/lib/FastLED/src_b2f8.cpp.o
    (symbol from plugin): in function `fl::CLEDController::mPHead':
(.text+0x0): multiple definition of `CFastLED::CFastLED()';
    /home/runner/work/FastLED/FastLED/.build/pio/teensy41/.fbuild/build/teensy41/release/core/FastLED_0a67.cpp.o
    (symbol from plugin):(.text+0x0): first defined here
...
(.text+0x0): multiple definition of `FastLED'; .../core/FastLED_0a67.cpp.o ...
(.text+0x0): multiple definition of `CFastLED::count()'; ...
(.text+0x0): multiple definition of `inoise16(...)'; .../core/noise_d3a4.cpp.o ...
(.text+0x0): multiple definition of `set_max_power_in_volts_and_milliamps(...)'; .../core/power_mgt_10f1.cpp.o ...
...
collect2: error: ld returned 1 exit status
FAILED: AnalogOutput
FAILED: Animartrix
FAILED: AnimartrixRing
FAILED: Apa102
FAILED: Apa102HD
FAILED: Async
FAILED: Audio
FAILED: AudioFftParity
[continues for ~60 more examples]

Note the path: the duplicated symbols come from …/build/teensy41/release/**core**/FastLED_*.cpp.o — i.e. compiled by fbuild as part of the core directory. That's the bundled FastLED that Teensyduino ships in cores/teensy4/.../libraries/FastLED/. fbuild 2.2.3 excluded it from the build; 2.2.4 no longer does.

Reproduce

git checkout master
# Confirm pyproject.toml has fbuild==2.2.4
# Push to a PR branch and run the teensy41 CI workflow

Failing run on FastLED master: https://github.com/FastLED/FastLED/actions/runs/26342702971

Environment

• fbuild: 2.2.4 (regression from 2.2.3)
• Host (relevant for CI): Linux runner (ubuntu-24.04)
• Board: teensy41
• Framework: framework-arduinoteensy 1.160.0
• Toolchain: toolchain-gccarmnoneeabi-teensy 1.110301.0

Likely root cause

Between 2.2.3 and 2.2.4, the source-discovery logic for the teensy41 framework changed to start picking up cores/teensy4/.../libraries/FastLED/. Possibilities:

1. A glob in framework-arduinoteensy library scanning got broadened (e.g. cores/*/libraries/** instead of just cores/* for the Arduino core itself).
2. The library-exclusion list for "this is the FastLED-bundled-in-core, not the user's FastLED" got dropped or its predicate broke.
3. The CMSIS-DSP fix from teensy41: link fails on Ports/PJRCSpectrumAnalyzer — missing CMSIS-DSP (arm_cortexM7lfsp_math) in link args #257 inadvertently widened the library include set in a way that swept the bundled FastLED in.

Most likely #3 since the regression appeared simultaneously with the #257 fix.

Suggested triage

1. Revert to 2.2.3's source-discovery logic for the teensy41 framework (the parts unrelated to the CMSIS-DSP link args).
2. Re-add the CMSIS-DSP -larm_cortexM7lfsp_math link arg on top of that, without touching source discovery.

🤖 Generated with Claude Code