Linux2026 - Updates for arm64 / Raspberry Pi

[danoli3]

Linux 2026

Draft for the makefile / download path split that matches current apothecary Linux artifacts.

Companion: openframeworks/apothecary#585 (Raspberry Pi aarch64 / armv7l / armv6l QEMU + GCC 10, all platforms green).

Lib paths (makefile + apothecary)

Target	ARCH	Path
Desktop x86_64	64	lib/linux/64
Generic aarch64	arm64	lib/linux/arm64
Raspberry Pi 64-bit	aarch64	lib/linux/aarch64
Raspberry Pi 32-bit v7	armv7l	lib/linux/armv7l
Raspberry Pi 32-bit v6	armv6l	lib/linux/armv6l

Legacy flat folders (linux64, linuxarmv6l, …) stay as addon fallbacks.

Official archives (GCC 10 baseline)

openFrameworksLibs_<tag>_linux_<ARCH>_gcc10.tar.bz2

download_libs.sh now:

• Detects Raspberry Pi so Pi 64-bit stays aarch64 (does not pull generic linux_arm64)
• Always requests _gcc10 for the five official Linux targets
• Extracts archives as-is (no --strip-components=1)
• Promotes leftover pre-0.13 flat folders up to lib/linux/<arch>
• Only removes the arch being installed

Status

• Draft, rebased onto master (2026-10-10): no merge commits; apothecary submodule at master's aac2679 (Linux modular library builds, xcode projects are gone from master branch? #593)
• Apothecary 585 already produces these paths and names

[danoli3]

Test run: Ubuntu 26.04 LTS, aarch64 (Parallels VM, Wayland, virgl GL 4.0 / Mesa 26.0.3)

Tested at 56d7b479 (same as pull/8540/head), system GCC 15.2.0, glibc 2.43.

Check	Result
scripts/linux/download_libs.sh	✅ Picked openFrameworksLibs_latest_linux_arm64_gcc10, SHA-256 verified, deployed to lib/linux/arm64
scripts/linux/compileOF.sh	✅ Release and Debug built with GCC 15.2, no warnings
examples/graphics/graphicsExample	✅ Builds; app launches under Wayland and keeps running with nothing on stderr
scripts/ci/linux/test_lib_paths.sh	✅ 30/30
tests/gl/glRenderSmokeTest	✅ GL_SMOKE_TEST RESULT=PASS frames=12 api=GL3.2 instancing=1
scripts/ci/linux/64/run_tests.sh	✅ Exit 0, every suite passed (e.g. 273/273, 100/100, 91/91)

Notes:

• Old lib/linux/aarch64 folders (kiss, tess2, openFrameworksCompiled) are detected and left in place, which is harmless.
• Minor: download_libs.sh logs Deployed libraries from [...] to [/libs]. The path in the message looks wrong, but the files land in the right place.
• Unrelated to this PR: a hand-built GCC 14 in /usr/local/gcc-14 fails to compile even a plain std::mutex on glibc 2.43 because of a stale include-fixed/pthread.h. The distro GCC works fine.

[danoli3]

RPi CI failure: apothecary GLFW built without X11/Wayland

Both rpi-build jobs (aarch64, armv6l) compile but fail at link of emptyExample:

ofAppGLFWWindow.cpp:791:  undefined reference to `glfwGetX11Window'
ofAppGLFWWindow.cpp:1810: undefined reference to `glfwGetWaylandDisplay'
ofAppGLFWWindow.cpp:1824: undefined reference to `glfwGetGLXContext'
collect2: error: ld returned 1 exit status

Cause

Checked the glfwGet* native symbols exported by libglfw3.a in the current apothecary latest packages:

package	native symbols
linux_64_gcc10	EGL, GLX, X11, Wayland
linux_aarch64_gcc10	EGL only
linux_armv6l_gcc10	EGL only

In apothecary formulas/glfw.sh (~line 132):

if [[ "$PLATFORM" =~ ^arm64$ ]] && [ "$TYPE" = "linux" ]; then
    GLFW_WAYLAND=1; GLFW_X11=1
else   # <- aarch64, armv6l, armv7l all land here
    DEFINES="$DEFINES -DGLFW_USE_EGL=1 -DGLFW_CLIENT_LIBRARY=glesv2"
    GLFW_WAYLAND=0; GLFW_X11=0
fi

The RPi workflow (build-linux-rpi.yml) builds with ARCH=aarch64, not arm64, so it takes the else branch and disables both X11 and Wayland. GLFW_USE_EGL / GLFW_CLIENT_LIBRARY are GLFW 3.2-era options that 3.4 ignores. The result is likely a null-platform-only GLFW that couldn't open a window on a Pi even if it linked (Bookworm defaults to Wayland).

Proposed fix (apothecary)

Build all Linux ARM targets with X11 and Wayland on. GLFW 3.4 still creates EGL/GLES contexts on either backend:

if [[ "$PLATFORM" =~ ^(arm64|aarch64|armv6l|armv7l|armv8)$ ]]; then
    export GLFW_WAYLAND=1
    export GLFW_X11=1
else

Then rebuild the RPi latest packages. The sysroot will probably also need libwayland-dev, libxkbcommon-dev, wayland-protocols and the X11 dev packages (libx11-dev, libxrandr-dev, libxinerama-dev, libxcursor-dev, libxi-dev), plus wayland-scanner on the host.

A stopgap would be to guard the X11/Wayland/GLX native calls in ofAppGLFWWindow.cpp for RPi/GLES builds. CI would go green, but we'd still be shipping a GLFW that can't open a window on a Pi.

[danoli3]

Apothecary fixed for raspberry Pi GLFW builds now. This is looking good.

[danoli3]

@ofTheo

== source contracts ==
OK config.shared.mk defines find_platform_lib_path
OK config.project.mk uses find_platform_lib_path for core libs
OK config.addons.mk uses find_platform_lib_path for addon libs

== MSYS2 ABI library paths expand without recursion ==
OK MSYS2 x86_64 paths expand
OK MSYS2 arm64 paths expand

== find_platform_lib_path (new wins, old is fallback) ==
OK linux/64: both present -> new path
OK linux/64: only new -> new path
OK linux/64: only old linux64 -> old path
OK linux/64: neither -> empty
OK linux/arm64: both present -> new path
OK linux/arm64: only new -> new path
OK linux/arm64: only old linuxarm64 -> old path
OK linux/arm64: neither -> empty
OK linux/aarch64: both present -> new path
OK linux/aarch64: only new -> new path
OK linux/aarch64: only old linuxaarch64 -> old path
OK linux/aarch64: neither -> empty
OK linux/armv7l: both present -> new path
OK linux/armv7l: only new -> new path
OK linux/armv7l: only old linuxarmv7l -> old path
OK linux/armv7l: neither -> empty
OK linux/armv6l: both present -> new path
OK linux/armv6l: only new -> new path
OK linux/armv6l: only old linuxarmv6l -> old path
OK linux/armv6l: neither -> empty

== PLATFORM_LEGACY_LIB_SUBPATHS aliases in config.shared.mk ==
OK makefile still maps linux/64 <-> linux64
OK makefile still maps linux/arm64 <-> linuxarm64
OK makefile still maps linux/aarch64 <-> linuxaarch64
OK makefile still maps linux/armv7l <-> linuxarmv7l
OK makefile still maps linux/armv6l <-> linuxarmv6l

Passed: 30 Failed: 0
Linux lib path fallbacks OK