release: use old bullseye container for release build#9
Merged
martinetd merged 2 commits intoflutter-elinux:masterfrom Feb 9, 2026
Merged
release: use old bullseye container for release build#9martinetd merged 2 commits intoflutter-elinux:masterfrom
martinetd merged 2 commits intoflutter-elinux:masterfrom
Conversation
When building with mesa 20 (debian bullseye) this define is missing, so backport it.
Building with trixie requires a recent glibc/stdc++ environment (GLIBC_2.38 / GLIBCXX_3.4.32), which might not be available on the target environment. Conversely, as far as libc/stdlib are concerned we are guarnateed to be able to run an old binary on a newer system, so building on a system as old as possible should address this particular issue. Unfortunately libflutter*so also link against system libraries (GL, X, wayland, fontconfig and many others), so if there is any so bump or imcompatible ABI then this is still far from perfect: future improvement should rebuild flutter-embedded-linux on demand for the required target, from flutter-elinux's CMake configuration The elinux embedded itself is not hard to build but libflutter_engine.so will be more work, so settle with "back to the old state" level for now.
|
Thanks @martinetd! No worries about overriding the PR - appreciate the quick turnaround on this, looking forward to the next release! |
Author
|
Thanks! I figured out why the release got much bigger too and opened #11 for that -- looks like a flutter build system bug... |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Building with trixie requires a recent glibc/stdc++ environment
(GLIBC_2.38 / GLIBCXX_3.4.32), which might not be available on the
target environment.
Conversely, as far as libc/stdlib are concerned we are guarnateed to be
able to run an old binary on a newer system, so building on a system as
old as possible should address this particular issue.
Unfortunately libflutter*so also link against system libraries
(GL, X, wayland, fontconfig and many others), so if there is any so bump
or imcompatible ABI then this is still far from perfect:
future improvement should rebuild flutter-embedded-linux on demand for
the required target, from flutter-elinux's CMake configuration
The elinux embedded itself is not hard to build but libflutter_engine.so
will be more work, so settle with "back to the old state" level for now.
Bullseye build broke on a single point, so there's a prerequisite patch, but it's trivial enough and should not be a problem.
I've tested running this on bullseye and on trixie so don't expect any problem with anything in between, this will be enough for the next immediate release.
I was also more annoyed than I thought I'd be at the bigger flutter engine .so release size since 3.32 (for example the arm64 debug libflutter_engine.so went from 83MB to 385MB!!!), so I'd like to have a look at that before the next release....
Hopefully by next week.
Cc @kabdelhalem -- thanks again, sorry to override your PR