eclipse executable cannot start on older, but still LTS versions, of many distributions

[jonahgraham]

The Eclipse executable on Linux now requires a newer glibc. This means that users who run or upgrade their Eclipse end up with an Eclipse that won't restart with an error similar to:

eclipse/eclipse: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by eclipse/eclipse)

This is because of the recent switch to using a newer OS version to build on that includes newer glibc:

equinox/Jenkinsfile

Line 20 in a1c46e9

containerTemplate(name: 'launcherbuild', image: 'eclipse/platformreleng-debian-swtnativebuild:12',

This is fairly annoying for users who simply install Eclipse as Eclipse won't work. But for users who upgrade a working 4.34 (aka 2024-12 or earlier) version of Eclipse to 4.35 end up with a broken installation for which I think there is no way of undoing the upgrade because eclipse itself no longer runs.

Note that this issue covers eclipse executable problem, but other native parts of Eclipse are also affected, particularly SWT.

Steps to reproduce a basic check, extract eclipse version and run with docker:

$ docker run --rm -it -v /tmp/eclipse-4.35:/work -w /work debian:11 eclipse/eclipse 
eclipse/eclipse: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by eclipse/eclipse)
eclipse/eclipse: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by eclipse/eclipse)

A more complete test using x11docker and an EPP version of Eclipse because it comes with bundled JRE:

$ x11docker  --share /tmp/eclipse-4.35  x11docker/xfce /tmp/eclipse-4.35/eclipse/eclipse
-- elided x11docker output --
/tmp/eclipse-4.35/eclipse/eclipse: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/eclipse-4.35/eclipse/eclipse)
/tmp/eclipse-4.35/eclipse/eclipse: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /tmp/eclipse-4.35/eclipse/eclipse)

An upgrade test runs the same as above, but start with a 4.34 eclipse, add --network to command line and add https://download.eclipse.org/releases/2025-03/ to available update sites and check for updates. After running check for updates and restarting user ends up with a non-functional Eclipse with the version `GLIBC_2.34' not found error messages

$ x11docker --network  --share /tmp/eclipse-4.34  x11docker/xfce /tmp/eclipse-4.34/eclipse/eclipse

Note that an update of x11docker/xfce may cause those examples to start working, that image is currently based on bullseye (debian 11) but may change at any point in the future

[laeubi]

@jonahgraham I think users if LTS distributions must use the eclipse distributed with the LTS (including java and whatever else), and I think IBM is offering "LTS Eclipse" versions. In anycase it would work to use an older launcher, but then SWT will fail the same way so I'm not sure it would help in any way to make the launcher use a lower glibc.

[jonahgraham]

What I propose is we do maintain two docker images:

• one older platformreleng-debian-swtnativebuild based on the oldest debian (or perhaps other distro) version we feel comfortable supporting. Use this for everything except GTK4 builds
• use platformreleng-debian-swtnativebuild:12 for GTK4 builds

I will be working on, and maintaining at least for the foreseeable future, a solution to this assuming we can reasonably agree.

The timeline that we need to roll this out by is for 2025-03, ideally by M3, which means we have just over 2 weeks to resolve this.

[jonahgraham]

@jonahgraham I think users if LTS distributions must use the eclipse distributed with the LTS (including java and whatever else), and I think IBM is offering "LTS Eclipse" versions. In anycase it would work to use an older launcher, but then SWT will fail the same way so I'm not sure it would help in any way to make the launcher use a lower glibc.

I may have been ok with that if there was an upgrade path (i.e. we don't blow up users' working installation when they install updates we recommend). I did cover SWT portion in the OP, I need to start somewhere and the launcher story is where I am starting on this.

[laeubi]

I need to start somewhere and the launcher story is where I am starting on this.

Better start on SWT... Equinox is not using any GTK4 at the moment, so it can use whatever docker image swt is using but not the other way round.

[jonahgraham]

Better start on SWT.

Thanks for the input. I want the first win of getting eclipse executable working on older systems first as it requires few changes (new docker container + single line change in equinox Jenkinsfile). If we can't get eclipse executable running on old systems in a way that is satisfactory then we don't need to invest anytime doing the more complicated problem of building SWT twice for gtk x86_64.

[laeubi]

I think this is fairly easy, just do what I did here:

• Add debian stable based image to build swt natives eclipse-platform/eclipse.platform.releng.aggregator#2441

and use FROM debian:10 and remove gtk4, then it should be deployed and can be used by equinox build.

[jonahgraham]

The other reason is if we can get eclipse working on old systems, but never fix SWT, then we can add tooling (maybe just warning/error message) to eclipse.c to handle the case where we are running on an unsupported system.

Right now we are in a pretty tough spot, last time we made such significant changes (e.g. new version of Java or new pgg signatures) time was spent on updating p2 and having a version deployed with that update p2 before the breaking/disruptive change was rolled out.

[jonahgraham]

I think this is fairly easy, just do what I did here:

Thanks, that is now what I plan to do. I am glad you have identified it as easy :-)

[laeubi]

Thanks, that is now what I plan to do. I am glad you have identified it as easy :-)

Just keep in mind, currently Equinox launcher is not working with Splash + GTK4 enabled so sooner or later someone might want to use GTK4 and then the same situation would arise to maintain two independent builds, I'm not sure this will work at all as while SWT has two so files for GTK3+4 there is only one launcher executable!

[iloveeclipse]

FYI: we at Advantest are forced to use "LTS" RHEL releases because we must guarantee for 5-10 years stable platform for semiconductor customers using our hardware. So we currently rebuild SWT & Equinox locally. For SWT I believe we did some dirty patch that comment out some GTK4 parts, equinox as simpler.
The result works fine on RHEL7.9 & RHEL 9.2.
Details if interesting can be given by my colleague @trancexpress.

[jonahgraham]

I'm not sure this will work at all as while SWT has two so files for GTK3+4 there is only one launcher executable!

You are correct, this will be tricky and we'll have to use our experience from SWT and apply it here when we are ready. I think if we are careful to make sure all the GTK3 splashscreens are in a gtk3 so, and likewise for gtk4 then the launcher can do the correct thing, at the expense of a more complicated build process. But that is something for another day.