Closed YoteZip closed 1 week ago
I believe goldberg used steamos (the distro that existed before the steam deck, based on debian 8) to build with a quite old glibc version.
I will create a pr for this and you might need to check it if works for you or not
You can try with this maybe? https://github.com/Detanup01/gbe_fork/actions/runs/10725445387
I was able to run a few of the workflows on that branch locally again, but I don't think I have access to the third party repos that get pulled in during build time? Obviously it's all failing in that PR - I'm guessing there's a pre-built protoc
binary somewhere being run as part of the build process, and that binary was probably built with a high glibc version. If that's true, and that binary can be rebuilt with e.g. Ubuntu-20.04 as well, that should move it a little further along.
oh yeah deps build as 22.04 isntead of 20.04. will fix that
You may already be aware but I think that it's trying to restore cached dependencies with the Restore deps
step - if these were previously built with Ubuntu 24.04 and re-used during this workflow that would explain why they are built with glibc 2.39 instead of the actual 20.04 runner. I looked throughout the source code and couldn't find any references to anything like Ubuntu-24.04
/22.04
/latest
etc, so there are limited places to look for something that is running with a high glibc version.
it was my bad it caches the dependency and its reusing all place thats why it errored out. now since i deleted and rerun the dependency and the new action should be able to build
I was able to run the Migrate/Gen Emu artifacts that built as part of this action on a Linux Mint 20 VM (aka same glibc as Ubuntu 20.04), so that looks good so far. It seems to still be re-using the emu-deps-linux-gmake2
cache for the rest though.
yes I trying my best. I never tried with this hopefully works
I've been testing the artifacts of this action and so far so good. I'm able to run all the tools and force DLC+inventory unlocks on a Linux game using the libsteam_api.so
and generated configs etc. Tested on Linux Mint 20 and Debian Stable for everything.
If works everything I will merge. Please test it. thy
Yeah looks good to me, as above I did some testing with all Linux artifacts on Linux Mint 20 (aka Ubuntu 20.04) and Debian Stable and it all works properly. For future compatibility I would continue basing the builds on the oldest supported Ubuntu LTS release, i.e. these timelines - specifically watch "End of Standard Support". It looks like GitHub deprecates the oldest Ubuntu runner exactly at the end of its lifecycle, so 20.04 should be switched to 22.04 around April 2025, and then from there, 22.04 should be switched to 24.04 in ~April 2027, and so on.
Hello, would it be possible for the Github workflow actions to use Ubuntu-20.04 as a base for better Linux compatibility? Debian Stable, Linux Mint 20/21, and Ubuntu-20.04/22.04 are notable Linux distros that I believe aren't able to run the executables generated from the current artifacts, as they use a
glibc
version that is older than Ubuntu-24.04's 2.39. Future versions ofglibc
have backwards compatibility but not vice versa, so compiling for the oldest supported LTS distro (Ubuntu-20.04) should generate executables that work for all modern Linux distros.I ran the
gen_emu_config-build-linux
andmigrate_gse-build-linux
workflows locally with Ubuntu-20.04 as a base and was able to generate executables that work on Debian Stable, but I'm not an expert with this fork so some sanity checking may be required to make sure it still behaves as expected. The tools in the standard Linux release, likegenerate_interfaces_x64
and such also have a similar problem.