cairo and glib: state the compiler floors instead of listing architectures

[th0ma7]

Split out of #7397, which was doing too much at once. This half is cairo and glib; the other half — the meson c_std overrides, the openexr / pngquant3 floors and the tvheadend ffmpeg bump — stays in #7397 and will rebase onto this once it lands.

Groundwork for #7391. These packages refused work by naming architectures. The reason was never the architecture — it was the compiler those architectures happen to ship — and an arch list cannot be lifted by a newer compiler, which is exactly what OVERLAY_GCC will offer.

package	was	now
cairo-latest	$(OLD_PPC_ARCHS) $(ARMv5_ARCHS)	MIN_GCC_VERSION = 4.8
glib-2.66	$(OLD_PPC_ARCHS)	MIN_GCC_VERSION = 4.6
glib-latest	$(OLD_PPC_ARCHS)	MIN_GCC_VERSION = 4.6

The two virtuals, cross/cairo and cross/glib, now pick their version by comparing TC_GCC instead of matching an architecture, so the selection follows the same line the floors draw.

Where 4.8 comes from

Measured on the Synology toolchains rather than taken from upstream gcc release notes. Core C++11 — unique_ptr brace-init, std::mutex, lambdas, -std=c++11:

gcc 4.3.7  no      gcc 4.6.4  no      gcc 4.7.3  no      gcc 4.8.3  yes      gcc 4.9.3  yes

cairo's __FLOAT_WORD_ORDER__ follows the same line — absent on 4.3.7 and 4.7.3, present from 4.8, and without it meson stops at "Could not get define 'FLOAT_WORD_ORDER'".

4.6 is where the two glib packages already sat: only the 2008 PowerPC compiler was excluded, ARMv5's 4.6.4 builds them. glib-latest's real requirement is far higher — cross/glib only ever selects it from gcc 7.5 — but that is the selector's business; the floor here restates the exclusion that was there, nothing more.

Blast radius

No architecture is freed. Every newly excluded one is a DSM 5.2 arch below the floor:

alpine  armada370  armada375  armadaxp  avoton  braswell  bromolow
cedarview  comcerto2k  evansport  qoriq  x64  x86         (all -5.2, gcc 4.3.7 … 4.7.3)

They were never named because DSM 5.2 is not built in CI, so nobody hit them. DSM 6.x and 7.x are untouched.

build.yml turns DSM 5.2 on temporarily so CI exercises exactly those archs. That commit reverts before merge.

The DSM 5.2 commit

Switching 5.2 on surfaced three failures the 5.2 toolchains have carried for as long as CI has not built them. None is about a capability floor; they are here because nothing else in this branch can be exercised on 5.2 until they are fixed. Each is verified by an actual build, not by inspection.

• cross/m4 (ppc853x-5.2, gcc 4.3.7) — format.c guards its in-function #pragma GCC diagnostic push/ignored/pop with _GL_GNUC_PREREQ (4, 3). gcc took #pragma GCC diagnostic at file scope from 4.2 but only allowed push/pop inside a function from 4.6, so 4.3 stops at "#pragma GCC diagnostic not allowed inside functions". Patched to ask for 4.6. Verified: cross/m4 builds for ppc853x-5.2.
• cross/libmaxminddb (x86-5.2 and x64-5.2, gcc 4.7.3) — the bundled libtap needs MAP_ANONYMOUS, which the pre-4.8 toolchains' headers only expose under _DEFAULT_SOURCE, and the package compiles with -std=c99, which turns that off. The -DMAP_ANONYMOUS=0x20 workaround was already there, behind an arch list naming 88f6281 ppc853x; x86 and x64 at 5.2 need it just as much and were simply never built. Keyed on gcc < 4.8 instead, which is exactly those four toolchains and nothing else — the same substitution this PR makes everywhere else. Verified: cross/libmaxminddb builds for x86-5.2.
• spksrc.spk-meta/videodriver.mk (x86-5.2) — the meta is selected by architecture alone, and x64_ARCHS contains the 5.2 archs, so every consumer pulled spk/synocli-videodriver into spk-stage1 on DSM 5.2, where that package can only stop at "DSM Toolchain 5.2 is lower than 6.2.4", failing the consumer with it (ffmpeg6 did). synocli-videodriver declares REQUIRED_MIN_DSM = 6.2.4; the selector now asks for the same. Verified: ffmpeg6 spk-stage1 pulls no meta at x86-5.2 and still pulls it at apollolake-7.1.

About the -7.1 builds

Touching cross/glib selects 21 SPK packages, and the four slowest DSM 7.1 archs do not finish them inside the 20700 s build budget. Those jobs report ERRORS: none and a partial build, not a failure — the same signature as #7399 and #7412, both merged that way. Splitting does not help here: cairo's package set is a subset of glib's, so this half is 21 packages however it is sliced.

ffmpeg5 and ffmpeg6

Both cross/ and spk/ Makefiles carried

# requires c11 and proper atomic using gcc-4.9+ support
UNSUPPORTED_ARCHS = $(ARMv5_ARCHS) $(ARMv7L_ARCHS) $(OLD_PPC_ARCHS)

— a comment naming 4.9 above a list that does not say 4.9. ffmpeg7 and ffmpeg8 already declare MIN_GCC_VERSION = 4.9; all four versions now express it the same way.

Nothing is freed: every arch the list named is below 4.9 at every DSM it has a toolchain for (88f6281 4.6.4, hi3535 4.8.3, ppc853x 4.3.7), and powerpc, ppc824x, ppc854x have no toolchain at all. What the floor adds is the fourteen toolchains the list silently admitted — qoriq-5.2 4.3.7, evansport-5.2 4.6.3, alpine/armada370/armada375/armadaxp/comcerto2k-5.2 4.6.4, avoton/braswell/bromolow/cedarview/x64/x86-5.2 4.7.3, monaco-5.2 4.8.3. All DSM 5.2, all below the stated requirement, none ever built. qoriq is the one that could have been hit outside 5.2: it is a PowerPC arch but not in OLD_PPC_ARCHS, so the list never covered it.

This lands here rather than separately because the videodriver-meta fix lets ffmpeg6 get past spk-stage1 on x86-5.2, where it would then reach the compiler its own comment says it cannot use.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JiBhJxRTbjD6HWSEjzE41g