[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

[danoli3]

Third-party addons with old (pre-0.13) library paths: tested on 61fdd4489

Machine: aarch64 Linux (Ubuntu 26.04 VM, g++ 15.2), so the project arch is linux/arm64. Both addons are cloned unmodified from upstream, and neither addon_config.mk was edited. Each addon's arm64 static lib was placed in the old flat folder lib/linuxarm64/, next to the addon's existing linux64 / linuxarmv6l / linuxarmv7l folders. The makefile has to find it through the new legacy fallback (linux/arm64 → linuxarm64 → linuxaarch64).

ofxTurboJpeg (armadillu/ofxTurboJpeg @ 06d14a7)

• libjpeg-turbo 2.1.5 built static for arm64 (NEON) into libs/turbo-jpeg/lib/linuxarm64/
• Link line picks up …/turbo-jpeg/lib/linuxarm64/libjpeg.a and …/libturbojpeg.a; the armv6l/armv7l libs are correctly skipped.

Check	Result
tjCompress to file (q90)	PASS, 13237 bytes
tjDecompress from file	PASS, 320x240
Round trip vs original	PASS, mean error 0.75 / 255
Memory buffer round trip	PASS, identical to file decode
FreeImage decodes the TurboJPEG file	PASS, diff 0.96 vs TurboJPEG decode

Note, not a linux2026 issue: the addon bundles a static libjpeg (API v62), and the executable exports its jpeg_* symbols over the system libjpeg.so.8 (v80) that libfreeimage uses. Without a workaround, ofImage::load() of any JPEG then fails inside the same app ("Wrong JPEG library version: library is 62, caller expects 80"). Adding PROJECT_LDFLAGS = -Wl,--exclude-libs,libjpeg.a:libturbojpeg.a to the project's config.make fixes it, and that's what the run above uses. The same thing would happen on master with this addon.

ofxLibwebsockets (robotconscience/ofxLibwebsockets @ f29422e)

• libwebsockets 1.4 (v1.4-chrome43-firefox-36, the version the addon's headers expect) built static for arm64 with OpenSSL, into libs/libwebsockets/lib/linuxarm64/
• Link line picks up …/libwebsockets/lib/linuxarm64/libwebsockets.a plus system -lssl -lcrypto -lz. The addon's x86_64 linux64 lib and the armv6l/armv7l libs are correctly skipped.

Check	Result
Server::setup() on port 9095	PASS
Client::connect() to ws://localhost:9095	PASS
5 messages client → server → echo → client	PASS, 5/5 matched

Screenshots

Screenshots of both test apps to follow.

[danoli3]

After extensive tests. @ofTheo what do you think I can do another pass with screenshots but I this this solves most problems with make and paths even using the new paths for libraries but supporting the old too

[danoli3]

Raspberry Pi OS (Trixie) Docker test results + downloader fix

Ran the linux2026 branch in Docker on an arm64 Mac (Colima), simulating Pi
hardware with the latest Raspberry Pi OS — Debian 13 "Trixie"
(n4jm4/raspberry-pi-os:trixie). ARMv6 was intentionally not run. Harness:
local ofLinuxTestScripts repo (scripts/run.sh rpios-trixie-*), OF checkout
at the head of this PR.

Results

Leg	Lib-path tests	Download + deployed-libs	Core build / unit tests
Pi 3/4/5 64-bit (linux/arm64, native)	✅ 35/35 (incl. new RPi fixtures; 30/30 before fix)	✅ aarch64 10/10, arm64 10/10	Core ✅ (-mcpu=cortex-a72). Tests ✅ after fix — see Finding 1
Pi 2/3 32-bit (linux/arm/v7, QEMU, armv7l, gcc 14.2)	✅ 35/35	✅ armv7l 10/10 (--allow-incomplete, as CI)	Core/unit-test compile not run to completion under QEMU (emulated build time); lib deployment verified

Finding 1 (fixed in 1d0f764, pushed to this branch)

Inside genuine RPi OS Trixie userland, nothing detected a Raspberry Pi:
/etc/os-release says ID=debian and containers expose no device-tree.
So the downloader fetched the generic linux/arm64 artifact (and kept an
explicit -a arm64) while the build expected linux/aarch64, failing with:

undefined reference to `tessTesselate' / `kiss_fftr_alloc'  (tests/addons/networkTcp)

Fix: is_raspberry_pi() (scripts/dev/download_libs.sh) and RPI_DETECTED
(config.shared.mk) now also accept RPi OS markers — /etc/rpi-issue and the
Raspberry Pi apt repo (archive.raspberrypi.org/.com) — and the downloader
normalises an explicit -a arm64 to aarch64 when a Pi is detected.
Regression coverage in scripts/ci/linux/test_lib_paths.sh (35/35, with
trixie-userland / device-tree / plain-Debian fixtures). Re-verified in the
container: detection fires, core builds to lib/linux/aarch64, and
tests/addons/networkTcp links.

Environment notes (not code bugs)

• tests/utils/fileUtils fails on a virtiofs-mounted checkout (mode-000
  fixtures); on a native filesystem it passes 91/91.
• tests/utils/strings fails 2/43 under a POSIX locale
  (ofToLower("AbCéÉBbCcc")); with LC_ALL=C.UTF-8 it passes 43/43.
• Test runner needs xauth for xvfb-run (added to the harness image).

Full logs: ofLinuxTestScripts/results/rpios-trixie-arm64-*.log,
rpios-trixie-armv7.log (local harness repo, available on request).

[danoli3]

Test harness used for the Raspberry Pi OS (Trixie) results above is now published: https://github.com/danoli3/ofLinuxTestScripts

Run with: ./scripts/run.sh rpios-trixie-arm64 (Pi 3/4/5, native) or ./scripts/run.sh rpios-trixie-armv7 (Pi 2/3, QEMU) against a local openFrameworks checkout on this branch.

[danoli3]

Running Popular Distros 2026 linux tests now

[danoli3]

2026 distro matrix — interim results (successes so far)

Added one-click (workflow_dispatch) workflows per distro to
danoli3/ofLinuxTestScripts
(.github/workflows/{mint,cachyos,pop,zorin,omarchy}.yml). Each checks out
this branch (linux2026), builds the distro image on a native amd64 runner,
and runs the OF tests, uploading the log as an artifact. Smoke = lib-path
tests; Full = download libs + deployed-libs check + core build + unit tests.

Distro (2026)	Base / image	Smoke	Full	Run
Linux Mint 22.2	linuxmintd/mint22.2-amd64 (official)	✅ 35/35	✅ PASS (20m19s)	run
CachyOS	cachyos/cachyos-v3 (official)	✅ 35/35	❌ FreeImage — see below	run
Pop!_OS 22.04	Ubuntu 22.04 + Pop apt repo (no official image)	✅ 35/35	❌ strings locale — fix pushed, re-running	run
Zorin OS 18	Ubuntu 24.04 base-equivalent (no credible image)	✅ 35/35	❌ strings locale — fix pushed, re-running	run
Omarchy	Arch userland (archlinux)	✅ 35/35	❌ FreeImage — see below	run

Findings

1. Arch family has no system FreeImage. Linux builds exclude the bundled
   copy (config.linux.common.mk: PLATFORM_CORE_EXCLUSIONS += $(OF_LIBS_PATH)/FreeImage/%) and link -lfreeimage, but Arch dropped
   freeimage to the AUR — core stops at FreeImage.h: No such file or directory on CachyOS/Omarchy. Harness fix (building AUR freeimage in
   the image) is pushed and re-running; a real fix would be for the Arch
   install_dependencies.sh to source FreeImage from AUR or for OF to stop
   excluding the bundled copy on Arch.
2. utils/strings is locale-sensitive (same as the Pi runs): 2/43 fail
   under the POSIX container locale (ofToLower/ofToUpper on é/É); passes
   with LC_ALL=C.UTF-8, now set in the workflows. Mint passes as-is.

Fixes pushed to the harness (59be9c1: UTF-8 locale, AUR FreeImage,
set -o pipefail so container failures fail the job — an earlier run masked
INSIDE_EXIT:1 as success). Full re-runs for Pop/Zorin/CachyOS/Omarchy are
in flight; will update this thread when they land.

[danoli3]

Test matrix: platforms and distros tested

Everything run against this PR so far, in one table. ✅ means it passed. Each row says which commit it was tested on: 91fc686bf is the current head (rebased onto master today), and 029798f03 is the head before the rebase. Files the rebase didn't touch are byte-identical between the two. The only merged differences are master's own changes, in download_libs.sh (#8591), the workflows (#8599) and a few core files.

CI (GitHub Actions)

Job	91fc686bf (current)	029798f03
Linux x86_64, GCC 10 / GCC 14	✅	✅
Linux x86_64, Ubuntu 22.04	✅	✅
Raspberry Pi aarch64 (cross)	✅	✅
Raspberry Pi armv6l (cross)	✅	✅
test-old-and-new-lib-paths	✅	✅
download-and-check-linux-64	✅	✅
macOS makefiles / Xcode	⏳ queued	✅
iOS, tvOS	✅	✅
Android arm64-v8a / armeabi-v7a / x86_64	✅	✅
Emscripten	✅	✅
MSYS2 ucrt64 / clang64 / clangarm64	✅	✅
Visual Studio 2022 / 2026, x64 / ARM64 / ARM64EC	✅	✅
validate (library downloads, from #8591)	⏳ queued	(new on master)

Linux distros: full run

"Full" means: download libs, check the deployed libs, build the OF core, and run the unit tests. These ran on 029798f03 with the one-click workflows in danoli3/ofLinuxTestScripts.

Distro	Arch	Lib-path tests	Full	Run
Linux Mint 22.2	x86_64	✅	✅	run
Pop!_OS 22.04	x86_64	✅	✅	run
Zorin OS 18 (Ubuntu 24.04 base)	x86_64	✅	✅	run
CachyOS v3	x86_64	✅	✅	run
Omarchy / Arch	x86_64	✅	✅	run
Kali Linux rolling	x86_64	✅	✅	run
Kali Linux rolling	arm64	✅	✅	run
NVIDIA Jetson L4T r36.2.0	arm64	✅ 40/40	✅ (Ubuntu arm64 libs)	run
Raspberry Pi OS Trixie (Pi 3/4/5, 64-bit)	aarch64	✅ 35/35	✅ core + unit tests	local, native arm64
Raspberry Pi OS Trixie (Pi 2/3, 32-bit, QEMU)	armv7l	✅ 35/35	✅ libs 10/10; core compile not run to completion under QEMU	local
Ubuntu 26.04 LTS (VM, Wayland, Mesa 26)	aarch64	✅ 30/30	✅ core, unit tests, graphicsExample runs, GL smoke test PASS (on 56d7b479)	local

Current head 91fc686bf, re-checked after the rebase

Check	Result
scripts/dev/tests/test-download-validation.sh (#8591's tests with this branch's download_libs.sh), Bash 3.2	✅
scripts/linux/download_libs.sh on Ubuntu 24.04 x86_64 (Docker)	✅ openFrameworksLibs_latest_linux_64_gcc10 deployed to lib/linux/64

Old (pre-0.13) addon library paths

Tested on 61fdd4489, Ubuntu 26.04 aarch64. The addons were unmodified upstream clones, with their libs in the old flat lib/linuxarm64/ folder, so they were found through the linux/arm64 → linuxarm64 / linuxaarch64 fallback.

Addon	Result
ofxTurboJpeg	✅ compress / decompress / round trip, memory buffers, FreeImage cross-check
ofxLibwebsockets	✅ server + client on localhost, 5/5 echoed messages

Fixes that came out of this testing (on this branch)

• 1d0f764c0 Raspberry Pi OS userland detection, so Pis get the aarch64 libs.
• 9704d872b, 3dc5f1f17 Linux uses apothecary's FreeImage (Arch dropped freeimage to the AUR; Linux (Arch/CachyOS): core build fails - system FreeImage gone (AUR-only), bundled apothecary copy excluded by OF makefiles apothecary#674).
• 6424d1042, 029798f03 Jetson detection, and the Ubuntu arm64 libs for L4T.

Not covered / known

• Real ARMv6 hardware (Pi Zero / Pi 1): only the CI cross-build, not run on a device.
• Fedora / openSUSE: not run yet.
• Environment-only failures, not OF bugs:
  • utils/strings needs a UTF-8 locale. Fixed separately in ofToLower / ofToUpper: use a UTF-8 locale when the environment has none #8593, and the workflows set LC_ALL=C.UTF-8.
  • utils/fileUtils permission fixtures fail only on virtiofs mounts (91/91 on a native filesystem).
• One side effect: after download_libs, the tracked libs/openFrameworksCompiled/lib/{linux64,linuxarmv6l,linuxarmv7l}/.gitkeep files show as deleted in git status (the old flat folders are moved to the new layout).

[danoli3]

All tests complete! Lets get this in and make plans for 12.2