Summary
On Teensy 3.x / LC builds, fbuild can select the bundled Teensy framework copy of FastLED even when the project already stages a local lib/FastLED.
That causes two FastLED copies to be compiled into the same link:
- project-local copy:
lib/FastLED/...
- bundled framework copy:
framework-arduinoteensy/.../libraries/FastLED/...
The result is a linker failure with duplicate definitions (CFastLED, FastLED, power-management helpers, noise/palette symbols, etc.).
Downstream breakage is currently tracked in FastLED/FastLED#2398.
Expected behavior
When a project-local lib/FastLED exists, fbuild should not compile the bundled Teensy framework libraries/FastLED copy for that build.
Acceptable outcomes:
- prefer the project-local library and ignore the bundled framework copy, or
- fail early with a clear unsupported/ambiguous-library error before link time.
The first option is the desired fix so FastLED can keep Teensy 3.x/LC on the fbuild path.
Observed downstream failure
FastLED CI fails on teensy30 after routing those boards through fbuild unconditionally:
- downstream regression:
FastLED/FastLED#2398
- failing board/job args:
teensy30 all
Symptoms in the failing link step:
multiple definition of 'CFastLED::CFastLED()'
multiple definition of 'FastLED'
multiple definition of 'set_max_power_in_volts_and_milliamps(...)'
The same log also shows ODR warnings between checked-out FastLED headers and the framework-bundled FastLED headers, which confirms that both copies are being compiled.
Minimal repro shape
A Teensy 3.x fixture or real build with:
- board:
teensy30 (or another Teensy 3.x / LC board)
- a project-local
lib/FastLED/ tree
- a sketch that includes
<FastLED.h>
Follow-up
Regression coverage for this path is already tracked separately in #195. This issue is for the actual library-selection / build-graph fix.
Summary
On Teensy 3.x / LC builds,
fbuildcan select the bundled Teensy framework copy ofFastLEDeven when the project already stages a locallib/FastLED.That causes two FastLED copies to be compiled into the same link:
lib/FastLED/...framework-arduinoteensy/.../libraries/FastLED/...The result is a linker failure with duplicate definitions (
CFastLED,FastLED, power-management helpers, noise/palette symbols, etc.).Downstream breakage is currently tracked in
FastLED/FastLED#2398.Expected behavior
When a project-local
lib/FastLEDexists,fbuildshould not compile the bundled Teensy frameworklibraries/FastLEDcopy for that build.Acceptable outcomes:
The first option is the desired fix so FastLED can keep Teensy 3.x/LC on the
fbuildpath.Observed downstream failure
FastLED CI fails on
teensy30after routing those boards throughfbuildunconditionally:FastLED/FastLED#2398teensy30 allSymptoms in the failing link step:
multiple definition of 'CFastLED::CFastLED()'multiple definition of 'FastLED'multiple definition of 'set_max_power_in_volts_and_milliamps(...)'The same log also shows ODR warnings between checked-out FastLED headers and the framework-bundled FastLED headers, which confirms that both copies are being compiled.
Minimal repro shape
A Teensy 3.x fixture or real build with:
teensy30(or another Teensy 3.x / LC board)lib/FastLED/tree<FastLED.h>Follow-up
Regression coverage for this path is already tracked separately in
#195. This issue is for the actual library-selection / build-graph fix.