Windows: linker fails with os error 206 (cmdline > 32 KB) on teensy41 — use @response file for link step

[zackees]

Summary

fbuild linker step fails on Windows with io error: The filename or extension is too long. (os error 206) for boards with many object files (e.g., teensy41). The total command-line length for the link invocation exceeds Windows' ~32 KB CreateProcess limit.

Repro

Project: FastLED/FastLED at commit 284b92af4c, on Windows 10, host bash, Blink example for teensy41.

$ bash compile teensy41 --examples Blink
...
   0.04 Toolchain: arm-none-eabi-gcc 11.3.1
   1.63 Linking firmware.elf
build error: io error: The filename or extension is too long. (os error 206)

Compilation succeeds; only the link step fails. (Note: requires FastLED PR fixing the prior section-conflict bug — without that fix the build fails earlier at compile time.)

Diagnosis

Object-file count and total path length on disk:

$ find .build/pio/teensy41/.fbuild/build/teensy41/release -name "*.o" | wc -l
505
$ find ... -name "*.o" | awk '{sum += length+1} END {print sum}'
54882

54,882 characters of .o paths alone, before adding the executable name, -o output, library flags, search paths, and linker scripts. Windows CreateProcessW rejects command lines beyond ~32,768 characters (ERROR_FILENAME_EXCED_RANGE = 206).

Why this works elsewhere but not Windows

OS	Cmdline limit	Status
Linux	~128 KB	Fits (CI runs Ubuntu — green)
macOS	~256 KB	Fits
Windows	~32 KB	Exceeded — link fails

CI is Ubuntu, so this regression is invisible to CI but blocks Windows developers.

Suggested fix

fbuild already uses GCC response files (@file) for compilation — see .fbuild/build/.../core/tmp/fbuild_teensy_*.rsp. The same approach should be applied to the link step:

1. Write all .o paths (and other long arg lists) to a response file under build/<board>/release/tmp/fbuild_link_<hash>.rsp.
2. Invoke the linker as arm-none-eabi-g++ @path/to/link.rsp.

Both gcc/ld/arm-none-eabi-g++ understand @file natively, so this is portable across toolchains. Apply unconditionally on Windows; on Linux/macOS it's a no-op safety net for future growth.

Affected boards (observed)

• teensy41 (~500 .o files; ~55 KB cmdline)

Other boards with large framework cores (Teensy 3.x, ESP32 with full IDF) likely affected too once their object counts grow.

Related FastLED PR

The companion fix for the section-conflict compile error (which gates this link-step failure from being visible) is at FastLED/FastLED [link will be added when PR is opened].