[bateske]

What changed

dot_a_linkage=true in the library.properties of CHGfx, CHGame and CHSd, so each library links from an archive and an object of it is pulled in only when the sketch calls into it. Recorded in board/CHANGELOG.md (Unreleased), platform/README.md, the CHGame README's RAM note and CHGame.h's header comment.

Why

A developer using board package 0.3.0 for audio:: and chgame_readButtons() only, with their own display code, found every sketch that includes CHGame.h carrying CHGfx's 8 KB framebuffer, its chunk buffers and its SRAM converters. Confirmed: Arduino links a library's objects whole, and CHGfx.cpp's strong DMA1_Channel3_IRQHandler replaces the core's weak default, so the vector table keeps the handler and the handler keeps the framebuffer, drawing or not.

Audio-only sketch	Flash	Static RAM
0.3.0 as released	4,580 B	9,712 B
With the flag	4,132 B	352 B

For the reviewer

• All 20 games and the 3 apps were built with and without the flag: sizes identical, release .bin byte-identical for all 23.
• The two hooks the libraries override (that DMA handler, and osSystickHandler in Audio.cpp) sit in the same objects as gfx_begin() and audio::begin(), so a sketch that uses the feature always gets them. Verified in the archive build's disassembly that the SysTick handler still calls the audio code.
• The -Os -flto builds produce slim LTO objects; plain riscv-none-embed-ar indexes them, so the link pulls the right members with no warning and no gcc-ar is needed.
• The developer's other idea, a root CHGameAudio.h, does nothing on its own (arduino-cli compiles every .cpp of a discovered library, and Draw.cpp includes CHGfx.h); with the flag, #include <CHGame.h> already costs nothing. Not added.
• A sketchbook copy of CHGfx would shadow the package's and lose the fix; arduino-cli says so with Multiple libraries were found for "CHGfx.h".
• The simulator does not read the flag. No library version bumped; it ships with the next package release.

🤖 Generated with Claude Code