Build launcher with older version of debian to limit glibc version required

[jonahgraham]

Doing this allows eclipse launcher to run on older Linux installs than the just the most recent versions. In particular this is important to ensure users who do check for updates end up with a still working eclipse launcher.

In addition, this commit introduces a check in the build process that the built eclipse/eclipse.so only contains the expected sets of dependencies.

The x86_64 PERMITTED_GLIBC_VERSION value is based on what Eclipse 4.34 used and what is now achieved again with this commit. For other linux platforms we don't enforce versions yet.

The check_dependencies.sh script was derived from work I did on CDT here

Requires eclipse-platform/eclipse.platform.releng.aggregator#2802

Fixes #830

[jonahgraham]

As with eclipse-platform/eclipse.platform.releng.aggregator#2802, I don't know how to test this on the build machine.

I can verify that it works locally.

Here is running the build with checklibs on my Ubuntu 24.04:

$ make -f make_linux.mak checklibs
Input info: CC:cc  PROGRAM_OUTPUT:eclipse  PROGRAM_LIBRARY:eclipse_11906.so  DEFAULT_OS:linux  DEFAULT_WS:gtk  DEFAULT_OS_ARCH:x86_64  M_ARCH:  M_CFLAGS:-fno-builtin-memcpy -fno-builtin-memmove  JAVA_HOME:/scratch/java/jdk-21.0.5+11  DEFAULT_JAVA:DEFAULT_JAVA_EXEC 
Verifying eclipse eclipse_11906.so have permitted dependencies
./check_dependencies.sh eclipse 2.7 libc.so.6 libpthread.so.0 libdl.so.2
ERROR: eclipse has dependency on glibc greater than allowed version of 2.7 for at least the following symbols
0000000000007fd0 R_X86_64_GLOB_DAT  __libc_start_main@GLIBC_2.34
0000000000007e98 R_X86_64_JUMP_SLOT  dlerror@GLIBC_2.34
0000000000007f40 R_X86_64_JUMP_SLOT  dlopen@GLIBC_2.34
0000000000007fa0 R_X86_64_JUMP_SLOT  dlsym@GLIBC_2.34
0000000000007fc8 R_X86_64_JUMP_SLOT  dlclose@GLIBC_2.34
make: *** [make_linux.mak:152: checklibs] Error 1

And here is using the image from eclipse-platform/eclipse.platform.releng.aggregator#2802:

$ docker run --rm -it -v$EQUINOX:$EQUINOX -w$LIBRARY_GTK swtgtk3nativebuild make -f make_linux.mak  checklibs
Input info: CC:cc  PROGRAM_OUTPUT:eclipse  PROGRAM_LIBRARY:eclipse_11906.so  DEFAULT_OS:linux  DEFAULT_WS:gtk  DEFAULT_OS_ARCH:x86_64  M_ARCH:  M_CFLAGS:-fno-builtin-memcpy -fno-builtin-memmove  JAVA_HOME:/usr/lib/jvm/justj-17  DEFAULT_JAVA:DEFAULT_JAVA_EXEC 
Verifying eclipse eclipse_11906.so have permitted dependencies
./check_dependencies.sh eclipse 2.7 libc.so.6 libpthread.so.0 libdl.so.2
./check_dependencies.sh eclipse_11906.so 2.7 libc.so.6 libpthread.so.0 libdl.so.2

[github-actions]

Test Results

  669 files  ±0    669 suites  ±0   1h 18m 1s ⏱️ + 4m 28s
2 223 tests ±0  2 176 ✅ ±0   47 💤 ±0  0 ❌ ±0 
6 813 runs  ±0  6 670 ✅ ±0  143 💤 ±0  0 ❌ ±0 

Results for commit e8faaa1. ± Comparison against base commit e35221a.

♻️ This comment has been updated with latest results.

[laeubi]

As with eclipse-platform/eclipse.platform.releng.aggregator#2802, I don't know how to test this on the build machine.

I think there are some ways to modify the pipeline, but I don't thing we need to complicate it, if you have tested it local and confident it works, the best is to merge it and check the next I-Build.

[tjwatson]

I do think that the updated glibc version requirement is going to be disruptive if it stays like it is for the 2025-03 release. But is there a similar effort going on to make SWT also to be able to run with an older glibc?

[jonahgraham]

But is there a similar effort going on to make SWT also to be able to run with an older glibc?

There is - I am doing that next. The launcher change was to test the waters.

I hadn't made the SWT issue report yet - I will do that now.

[jonahgraham]

I hadn't made the SWT issue report yet - I will do that now.

Done. eclipse-platform/eclipse.platform.swt#1791

[merks]

FYI, there has already been some negative impact from the lack of backward compatibility, and that's being noticed during the early milestone phases:

eclipse-oomph/oomph#128

[HannesWell]

As with eclipse-platform/eclipse.platform.releng.aggregator#2802, I don't know how to test this on the build machine.

Once we have submitted that change and build and deployed the new docker-image the Jenkins build should pick-up your changes automatically (maybe a committer has to rebuild it since changes from non-committers might not be picked-up from PRs).
Then the newly built binary are attached to the build. If the build is successful there should be then:
https://ci.eclipse.org/releng/job/equinox/job/PR-834/lastSuccessfulBuild/artifact/equinox.binaries

[HannesWell]

The change looks good and the latest build with it applied succeeded.

You can get the built Equinox launcher executable and native launcher libraries from Jenkins:
https://ci.eclipse.org/releng/job/equinox/job/PR-834/8/artifact/equinox.binaries/

Since the I-build just started, I'd leave this open for comments until tomorrow Wednesday (European) evening and submit it then, unless there are (major) objections.

[HannesWell]

I cannot answer that with certainty, but in general each OS is independent and as we didn't change anything there recently I think it's currently fine. Of course it could be interesting for the future.
But I recall there have been issues in the past, which I think is the reason that the binaries for mac on x86_64 and aarch64 are both compiled on the ARM machine.

But unless we can define a suitable check for mac now, this should be converted into a statement.

[jonahgraham]

You can get the built Equinox launcher executable and native launcher libraries from Jenkins:
https://ci.eclipse.org/releng/job/equinox/job/PR-834/8/artifact/equinox.binaries/

I have tested these artifacts on x86-64 against the original use cases in #830. I tested them locally on my Xubuntu 24.04 and with docker on Debian:11.

Here are the specific steps I ran on my host machine. (Note I have java located in /scratch/java/jdk-21.0.5+11/bin/java, adjust for your vm location as needed)

$ mkdir -p /tmp/eclipse-4.35
$ cd /tmp/eclipse-4.35
$ rm -rf *
$ tar xf ~/Downloads/eclipse-platform-I20250203-0500-linux-gtk-x86_64.tar.gz 
$ $PWD/eclipse/eclipse -data data -consoleLog -vm  /scratch/java/jdk-21.0.5+11/bin/java
# eclipse starts successfully
$ x11docker --share /scratch --share $PWD x11docker/xfce -- $PWD/eclipse/eclipse -data data -consoleLog -vm  /scratch/java/jdk-21.0.5+11/bin/java
# eclipse fails (as expected) with glibc errors as x11docker/xfce is FROM debian:11 which has older glibc
# output contains this:
# /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)

# download eclipse and eclipse_11907.so from build artifacts
$ cp  ~/Downloads/eclipse eclipse/
$ cp  ~/Downloads/eclipse_11907.so eclipse/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.2.1300.v20241223-1657/
$ rm eclipse/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.2.1300.v20241223-1657/eclipse_11906.so
$ x11docker --share /scratch --share $PWD x11docker/xfce -- $PWD/eclipse/eclipse -data data -consoleLog -vm  /scratch/java/jdk-21.0.5+11/bin/java
# eclipse launcher now works - note that swt fails so IDE doesn't open, but that is expected until 
# SWT is fixed https://github.com/eclipse-platform/eclipse.platform.swt/issues/1791
# output contains this:
# java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons: 

$ $PWD/eclipse/eclipse -data data -consoleLog -vm  /scratch/java/jdk-21.0.5+11/bin/java
# eclipse still starts successfully on Xubuntu 24.04 

I'll now push the comment cleanup. Let me know if there is anything else you think I should write or test.