Linux

Linux gets a GTK plugin that puts the same renderer core behind Flutter’s GTK embedder. CMake runs the setup when Flutter configures the build, so there’s no step to run by hand. There are two requirements Flutter’s own Linux instructions won’t have prepared you for: a recent glibc, and LLVM’s C++ standard library.

Seen in one place so far

The only Linux that has drawn a frame is arm64, in a Debian 13 container on an Apple silicon Mac, against Mesa’s software rasterisers. No real GPU has run it, and neither has an x86_64 machine: that build takes Google’s x86_64 release in exactly the same way, and nobody has built it yet. There’s no Linux job in CI either. If you run it on a desktop, please say on the Discord how it went.

What you need

x86_64 or arm64	The two architectures Google publishes a Linux release for
glibc 2.38 or newer	Check with ldd --version. Why
clang, with libc++	Not GCC, and not libstdc++. Why
Flutter’s Linux toolchain	CMake, Ninja, pkg-config and the GTK 3 headers
A display	GTK opens a window. Without one

glibc 2.38 or newer

Filament’s Linux release is built on a recent system. Its matc asks for GLIBC_2.38, and its libraries call __isoc23_sscanf, which older versions don’t have. On an older glibc the setup fails when matc won’t start, or the link fails on a missing symbol version.

Distribution	glibc
Debian 13 (trixie)	2.41	Where it has drawn
Ubuntu 24.04	2.39	New enough. CI runs this release’s matc there, though not the Linux build
Debian 12 (bookworm)	2.36	Too old
Ubuntu 22.04	2.35	Too old

clang and libc++

Filament’s archives are built against LLVM’s standard library, so every C++ symbol in them is named in std::__1, which GNU’s libstdc++ doesn’t have. Linking them against libstdc++ leaves every one of those symbols undefined. The plugin’s CMake file passes -stdlib=libc++ on both the compile and the link line, so all you need is clang and the libc++ packages installed.

Installing the packages

On Debian or Ubuntu, this is the list the tested container installs:

sudo apt-get install \
  ca-certificates curl git unzip xz-utils zip file \
  clang lld libc++-dev libc++abi-dev \
  cmake ninja-build pkg-config \
  libgtk-3-dev liblzma-dev libglu1-mesa-dev \
  libegl1-mesa-dev libgles2-mesa-dev libgl1-mesa-dev

It’s probably more than the minimum. Nobody has trimmed it, so this is the list known to work. On another distribution the names differ, and what you’re after is clang, libc++ and libc++abi, CMake, Ninja, pkg-config, and the GTK 3, EGL and OpenGL headers.

Running it

flutter run -d linux

The first build downloads Filament’s Linux release, 52 MB (51 MB on arm64), and compiles the materials for Vulkan and OpenGL. The setup picks the release by uname -m. To pick for another architecture, set ORBLIT_FILAMENT_ARCH to x86_64 or aarch64.

The renderer asks for Vulkan first, through libvulkan.so.1, and falls back to OpenGL through libGL.so.1. A desktop with working graphics drivers has both. Each frame is copied into an FlPixelBufferTexture on its way to Flutter, because the GTK embedder offers no copy-free route.

Without a display

GTK needs a display to open a window on, so a server or a container needs a virtual one. Xvfb does the job, and Mesa’s llvmpipe (OpenGL) and lavapipe (Vulkan) will draw without a GPU:

sudo apt-get install xvfb x11-utils xauth \
  mesa-utils libgl1-mesa-dri mesa-vulkan-drivers vulkan-tools

The engine’s tool/ci_draw_frame_linux.sh takes a built bundle, starts Xvfb if there’s no display, and waits until the renderer reports a drawn frame.

In a container

If your machine isn’t a suitable Linux, the engine carries the container it was built in: Debian 13, Flutter 3.47.0, clang with libc++, Mesa’s software drivers and Xvfb. It needs Docker and a clone of the engine:

git clone https://github.com/ChxisB/orblit.git
cd orblit
docker build -t orblit-linux:trixie tool/linux_container
docker run --rm -v "$PWD:/work" -v orblit-pub-cache:/root/.pub-cache \
  orblit-linux:trixie \
  bash -c 'cd /work/examples/gallery && flutter pub get && flutter build linux --debug'

That builds the engine’s own gallery. For your own app, run the same docker run from your app’s directory, with cd /work in place of cd /work/examples/gallery. The image is only built once.

Two traps, both from the checkout being shared with the container:

• Keep the pub cache in a volume, as the -v orblit-pub-cache:… above does. Without it, package_config.json survives in your checkout while the packages it names are thrown away with the container, and the next build fails inside Flutter itself with 'Matrix4' isn't a type.
• Run flutter pub get on your own machine afterwards. The one package_config.json can only hold one machine’s paths, and after a container build it holds the container’s.