libgdx / Jamepad

A better way to use gamepads in Java
Apache License 2.0
19 stars 11 forks source link

Lower GLIBC requirements by using chromium reversion script and patches #22

Closed theofficialgman closed 10 months ago

theofficialgman commented 1 year ago

Follows the same approach as the chromium sysroot creator to lower GLIBC requirements for builds produced on the github actions https://source.chromium.org/chromium/chromium/src/+/main:build/linux/sysroot_scripts/sysroot-creator.sh;l=754

All produced linux binaries (x86, x86_64, armhf, and arm64) have had their minimum requirements lowered to GLIBC 2.17 or lower.

Useful for linux games such as https://github.com/00-Evan/shattered-pixel-dungeon/issues/1407

Actions passing (except deployment to maven which I obviously cannot do): https://github.com/theofficialgman/Jamepad/actions/runs/5226513669

MrStahlfelge commented 1 year ago

Yes, the run succeeds. However, I can't really judge what this changes. Is there any documentation available?

theofficialgman commented 1 year ago

Please read the comments in the changes of the PR and the downloaded reversion_glibc.py file and respond with any questions after having done that.

theofficialgman commented 1 year ago

@MrStahlfelge please give questions on the PR if you have any.

The purpose is the remove higher versioned GLIBC symbols for which lower verisioned symbols already exist. and remove entirely symbols that do not exist in lower versions of GLIBC. This results in compilation of any program in the actions to link to lower GLIBC since there will be no symbols remaining from versions higher than 2.17.

MrStahlfelge commented 1 year ago

As someone not really familiar with C compiler, I can't see the overall concept of what's happening here - that's why I asked for a general documentation explaining the background and approach. Moreover and even more important, it is not clear for me what has to be done when we have to switch to the next OS version. It might not work anymore, with no one able to fix it.

theofficialgman commented 1 year ago

sorry there really isn't any documentation. the best you are going to get is the code snippit from chromium and the comments included there. https://source.chromium.org/chromium/chromium/src/+/main:build/linux/sysroot_scripts/sysroot-creator.sh;l=747-794?q=reversion_glibc.py&ss=chromium

like I said, the libc binaries have symbols in them that define what standard libc function and what versions are supported by the local system. Compilers (like GCC) which link to these symbols use these "lists" to determine which version and what symbols they have available to them when compiling. The changes here simply remove entires from the "lists" that are higher than 2.17 so that the compiler produces binaries that are compatible with targets with a minimum of GLIBC 2.17 required.

if you switch to the next OS version (jammy) you likely won't have to do anything except maybe integrate the c++config.h header change as documented here https://source.chromium.org/chromium/chromium/src/+/main:build/linux/sysroot_scripts/sysroot-creator.sh;l=770-773?q=reversion_glibc.py&ss=chromium This header does not exist on focal since the default G++ is 9.4.0 and this header was only added in G++ 10

00-Evan commented 1 year ago

Hey @theofficialgman , just wanted to chime in that it looks this same thing may become an issue in the next release of libGDX, see here: https://github.com/libgdx/libgdx/pull/7005

This would presumably mean that any game built using libGDX 1.12.0 (whenever it eventually releases) would drop support entirely for versions of glibc prior to v2.29. You might consider offering your fix to the main libGDX repo as well, or at least starting a discussion there about it. This would have the benefit of providing a template for libGDX sub-projects like Jamepad to use.

theofficialgman commented 1 year ago

@00-Evan I'm not super familiar with the project but to my knowledge the main libgdx repo doesn't actually build any binaries. It pulls/downloads them from a maven repo which this repo (and the other subproject repos) updates on release. I believe the main libgdx repo only packages all these projects up into jars basically which is why no changes there are necessary or would do anything.

00-Evan commented 1 year ago

@theofficialgman I could be wrong but I do think this change will impact the natives that libGDX distributes. They list the following in their CHANGES.md file in 1.11.1 (which I think is going to be renamed to 1.12.0): - [BREAKING CHANGE] Dropped support for older libc versions since libGDX is now built on Ubuntu 20.04 (#7005) https://github.com/libgdx/libgdx/blob/master/CHANGES

theofficialgman commented 1 year ago

@theofficialgman I could be wrong but I do think this change will impact the natives that libGDX distributes. They list the following in their CHANGES.md file in 1.11.1 (which I think is going to be renamed to 1.12.0): - [BREAKING CHANGE] Dropped support for older libc versions since libGDX is now built on Ubuntu 20.04 (#7005) https://github.com/libgdx/libgdx/blob/master/CHANGES

Nope. Read above what I wrote. The GitHub actions at libgdx repo only download binaries and pack them into jars (jars are zips). The binaries aren't actually built at the GitHub actions at libgdx repo, they are built at each individual sub repo such as this one.

theofficialgman commented 1 year ago

@00-Evan nevermind you are correct. I missed the native compilation step in the workflow over at libgdx. yes it needs to be done there too for the libgdx, box2d, bullet, and freetype native binaries https://github.com/libgdx/libgdx/blob/master/.github/workflows/build-publish.yml#L147

theofficialgman commented 1 year ago

@00-Evan PR added https://github.com/libgdx/libgdx/pull/7177