fix(build): make BuildLinux.sh work on clean Debian, Fedora and Arch systems

[YeeP79]

Summary

BuildLinux.sh currently cannot bootstrap a build on a clean system for any of the three distributions it nominally targets. This PR fixes the dependency handling for Debian and Fedora, adds the missing Arch definition, and stops the GUI link step from requiring a Mesa component that several distributions no longer ship.

Each change is a separate commit and each is independently useful.

Distribution	Before	Cause
Debian	BuildLinux.sh -u exits 1 immediately	set -e plus a grep that matches nothing on a machine without GTK3
Fedora	-u exits 0, build fails much later at link	mesa-libOSMesa-devel is obsoleted on F42 and installs nothing
Arch	BuildLinux.sh exits 1, "distribution does not appear to be currently supported"	no linux.d/arch

The libOSMesa problem

src/slic3r/CMakeLists.txt links OSMesa unconditionally on Linux, with no find_library probe and no build option. That was safe when every distribution shipped the classic Mesa off-screen renderer. It no longer holds.

Fedora 42 obsoletes the package that linux.d/fedora asks for:

$ dnf repoquery --obsoletes '*' | grep -i osmesa
mesa-libOSMesa < 25.1.0~rc2-1
mesa-libOSMesa-devel < 25.1.0~rc2-1

Because it is obsoleted with no replacement pulled in, dnf install -y mesa-libOSMesa-devel prints Complete! and installs nothing. BuildLinux.sh -u exits 0, so the problem is invisible until the link step:

/usr/sbin/ld: cannot find -lOSMesa: No such file or directory

The library moved to mesa-compat-libOSMesa-devel, which provides /usr/lib64/libOSMesa.so. Installing that makes -lOSMesa resolve again.

Arch has no usable provider at all. Current mesa (26.1.5) ships no OSMesa files, and the only package that does is mesa-amber, a legacy 21.3.9 compatibility build which declares Conflicts With: mesa. Installing it would remove the regular Mesa stack from the machine doing the build, so it is not something a dependency list can reasonably ask for.

Prior art

The AUR package bambu-studio hit exactly this and has carried a local patch since 2026-04-19, 0001-src-slic3r-CMakeLists.txt-avoid-linking-to-the-depre.patch, which drops OSMesa from the link line entirely and depends on plain mesa. That package builds and runs, which is useful evidence that the off-screen renderer is not required for a working build.

Removing the link outright would regress distributions that still ship the library, so this PR probes for it instead and links it only when present. Debian still finds and links it exactly as before; Arch and any other distribution without it fall back to the EGL context path already configured immediately below.

Changes

• fix(cmake) — probe for libOSMesa with FIND_LIBRARY and link it only when found.
• fix(build) — Fedora: mesa-libOSMesa-devel → mesa-compat-libOSMesa-devel.
• fix(build) — Debian: tolerate the empty grep match, matching what linux.d/fedora already does with || true. Without this, -u (whose only job is installing the dependencies) requires the dependencies to already be installed.
• feat(build) — add linux.d/arch. Arch reports ID=arch and sets no ID_LIKE, so the candidate loop matched nothing. Arch ships headers with the runtime package, so there is no -dev/-devel split to mirror, and pacman --needed makes the per-package pre-filtering the dpkg and rpm paths perform unnecessary.

Testing

All testing was done in the same container images the release workflow uses, starting from a clean image each time.

Arch (archlinux:latest, GCC 16.1.1) — full build from scratch:

./BuildLinux.sh -u    exit 0
./BuildLinux.sh -d    exit 0
./BuildLinux.sh -s    exit 0

CMake took the fallback path (OSMESA_LIBRARIES-NOTFOUND), produced build/src/bambu-studio, and the resulting binary runs:

$ ./bambu-studio --help
BambuStudio-02.08.01.55:
Usage: bambu-studio [ OPTIONS ] [ file.3mf/file.stl ... ]

ldd confirms no libOSMesa dependency. No extra toolchain workarounds were needed — in particular FFMPEG built cleanly, so no LTO or C-standard overrides.

Debian (debian:trixie) — -u now exits 0 and installs libgtk-3-dev and libOSMesa.so; -d and -s both exit 0. To confirm the guard changes nothing where the library does exist, the generated link line for src/bambu-studio was compared against an unpatched reconfigure of the same tree with the same prebuilt dependencies:

unpatched:  -lOSMesa, -lOSMesa                             (210 link entries)
patched:    /usr/lib/x86_64-linux-gnu/libOSMesa.so  (x2)   (210 link entries)

Same library, same two positions, same total: find_library resolves to exactly the file the -l flag would have found. Neither build records a NEEDED entry for it, because GLFW loads the off-screen renderer with dlopen rather than linking against it directly.

Fedora (fedora:42) — verified before and after: linking -lOSMesa fails with the currently-listed package and succeeds with mesa-compat-libOSMesa-devel.

Note on #11321 / #11323

This overlaps with the native-packaging work in #11323 — the Arch and Fedora jobs there cannot currently get past the dependency and link steps for the reasons above. This PR is deliberately scoped to BuildLinux.sh and the GUI link only, and stands on its own for anyone building from source; it does not touch packaging or CI.

[YeeP79]

Some additional context on the fix(cmake) commit: the unconditional OSMesa link is the root cause behind a cluster of long-standing reports, so this is a bit more than an Arch enablement change.

Mesa retired the classic OSMesa build in 25.1 (Fedora's obsoletes marker is mesa-libOSMesa-devel < 25.1.0~rc2-1). Distributions handled that differently: Fedora moved the library into mesa-compat-libOSMesa-devel, while Arch dropped it from mesa altogether, leaving only mesa-amber, which declares Conflicts With: mesa. Anything that hard-links libOSMesa therefore stops building or starting once a distribution ships Mesa 25.1.

Reports that trace back to this:

• Mesa 21.3+ change effects Bambu Studio #6951 — Mesa 21.3+ change effects Bambu Studio
• Wont launch due to libOSMesa.so.8 update / dependencies. Garuda linux #7017 — Wont launch due to libOSMesa.so.8 update / dependencies
• libOSMesa.so.8: cannot open shared object file: No such file or directory #7528 — libOSMesa.so.8: cannot open shared object file

Worth noting that PrusaSlicer, which this project is based on, has no reference to OSMesa anywhere in its CMake files or sources — the link was added downstream. Making it conditional brings the Linux build back in line with upstream while leaving distributions that still ship the library completely unaffected (verified above: the Debian link line is byte-for-byte equivalent).

One scope caveat so this isn't over-read: the change fixes builds from source. Users on the official AppImage or on distro packages built from the release tarball only benefit once a release is produced with it.