Build GTK3 support for linux x86-64 to maximize compatibility

[jonahgraham]

Build GTK3 support for linux x86-64 to maximize compatibility

Recently all SWT builds for Linux x86-64 have been done on a new Debian image. This leads to requiring such a new distro to be able to run SWT successfully.

This change builds GTK3 and common code on an older debian container to increase the range of versions we support. Only GTK4's key library, libswt-pi4-gtk*.so is shipped from a build on the new debian container.

We continue to build all of the natives on latest debian so we benefit from compiler warnings/errors and other such tooling.

As part of the build all .so files are checked to ensure their dependencies are as expected. In particular glibc version is checked for all symbols and all libraries are checked.

The version of glibc 2.14 was chosen as that is what the effective requirement has been for a while for SWT (at least since Eclipse 4.26/2022-12)

Fixes #1791

The way I have tested this concept locally is to run the build.sh twice on my local machine using the two docker containers mentioned in runOnNativeBuildAgent of the Jenkinsfile*:

0. Start in root of SWT repo: cd /scratch/eclipse/oomph/swt-master/git/eclipse.platform.swt/
1. Collect the sources to build java -Dws=gtk build-scripts/CollectSources.java -nativeSources 'target/natives-build-temp/gtk'
2. cd 'target/natives-build-temp/gtk'
3. Build GTK4 version: docker run --rm -it -v/scratch:/scratch -w$PWD -e SWT_JAVA_HOME=/scratch/java/jdk-17.0.13+11 -e OUTPUT_DIR=/scratch/eclipse/oomph/swt-master/git/eclipse.platform.swt/binaries/org.eclipse.swt.gtk.linux.x86_64 swtnativebuild ./build.sh -gtk4 install
4. Build GTK3 version docker run --rm -it -v/scratch:/scratch -w$PWD -e SWT_JAVA_HOME=/scratch/java/jdk-17.0.13+11 -e OUTPUT_DIR=/scratch/eclipse/oomph/swt-master/git/eclipse.platform.swt/binaries/org.eclipse.swt.gtk.linux.x86_64 swtgtk3nativebuild ./build.sh -gtk3 install
5. Then try running various snippets with GTK3 and GTK4 in the IDE
6. Using "Show Command Line" option in launch configuration extract full command line and reproduce the run with x11docker

* Note that I actually built them manually with USER 1000 at the end of the file so I can share directories with the container. There are more details in the step-by-step in eclipse-platform/eclipse.platform.releng.aggregator#2802 (comment)

[jonahgraham]

@laeubi and/or @HannesWell How to test this?

Can I push to a branch of SWT so I can run builds on https://ci.eclipse.org/releng/job/eclipse.platform.swt/?

If so, any objections to me merging eclipse-platform/eclipse.platform.releng.aggregator#2802 now so that I can start to test this?

Also, assuming that is the way to test, can you check out if always push new natives is ok?

[github-actions]

Test Results

   502 files  ±0     502 suites  ±0   9m 44s ⏱️ -16s
 4 334 tests ±0   4 320 ✅ ±0   14 💤 ±0  0 ❌ ±0 
16 575 runs  ±0  16 466 ✅ ±0  109 💤 ±0  0 ❌ ±0 

Results for commit 4c3f4bc. ± Comparison against base commit 54dad6c.

♻️ This comment has been updated with latest results.

[HannesWell]

Also, assuming that is the way to test, can you check out if always push new natives is ok?

In general the policy is that all SWT native binaries have to be build on project infrastructure and to ensure this we usually don't accept changes in the binaries directly from PRs but just receive the code changes and only rebuild on master what is eventually added to the git/p2-repo.

In order to test the newly built binaries you can just download the built artifacts from Jenkins. E.g. for the second build:
https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/PR-1795/2/artifact/eclipse.platform.swt/binaries/org.eclipse.swt.gtk.linux.x86_64/target/

I've just created a PR to clean up the archived artifacts a bit: #1799

In the past there have been discussions about how to stream-line this process, especially as the required build-resources are currently rare (I hope this changes in the future: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/4231).
But I think if this is changed, it should be a separate, dedicated PR.

For all the other changes I need a bit more time to review. I intend to do it tomorrow.

[jonahgraham]

Also, assuming that is the way to test, can you check out if always push new natives is ok?

In general the policy is that all SWT native binaries have to be build on project infrastructure [...]

I will remove that commit then and apply your ternary change.

[laeubi]

@jonahgraham If you change any of the C files or build scripts a little bit (e.g. add a temporary comment) then the "build natives" workflow should kick in and build things with your changed containers.

What I have done for GTK4 back then was that I first checked the build is running, and then look at the build output (e.g. did the GTK4 binaries produced) and finally that all the so files are attached as desired.

If that works (and the tests not go completely wild) there is a good chance that the change is good to be submited and a committer can then run a build with forced binary generation.

[HannesWell]

@jonahgraham If you change any of the C files or build scripts a little bit (e.g. add a temporary comment) then the "build natives" workflow should kick in and build things with your changed containers.

Alternatively you can just start a build via Build with parameters and check the forceNativeBuild box:

With #1799 being submitted the build native fragments are now prominently displayed as the only Build artifacts in the corresponding Jenkins job and can be downloaded and further inspected and tests. The current build is waiting for the Y-build tests to complete and will therefore need some more time, but the previous build failed:
https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/PR-1795/5/

For example for the master you can see it already:
https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/master/921/

I have to leave now for a few hours but, when back I'll review this in detail and make a few more suggestions for enhancements.

[HannesWell]

Below I have made a few suggestions for making this change a bit more compact and one required change to fix the pipeline failure.

With that applied the build succeeds:
https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/PR-1795/7/

You can obtain the newly built native jars from that runs Build-artifacts section on the overview page or just visit it directly at:
https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/PR-1795/7/artifact/eclipse.platform.swt/binaries/

[jonahgraham]

With that applied the build succeeds:

Is the "that" in this comment that you changed the Jenkinsfile via "Replay" feauture? Because AFAICT run 6 failed and run 7 succeeded, but they were both built from same SHA1 but there is a diff in the replay https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/PR-1795/7/replay/diff

Not a feature I had been familiar with until now. Thanks for the demo.

[laeubi]

Alternatively you can just start a build via Build with parameters and check the forceNativeBuild box

Yes but this only works for committers and especially when testing different approaches it is a bit inconvenient, but of course many things work (including replay).

[iloveeclipse]

Is this still in the draft state? Would be great to have it before M3.

Issue has been addressed.

[HannesWell]

With that applied the build succeeds:

Is the "that" in this comment that you changed the Jenkinsfile via "Replay" feauture? Because AFAICT run 6 failed and run 7 succeeded, but they were both built from same SHA1 but there is a diff in the replay https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/PR-1795/7/replay/diff

Not a feature I had been familiar with until now. Thanks for the demo.

Yes "that" was meant to be the changes suggested/described before. Should have been more clear.
But you got it exactly right. You're welcome. :)

Alternatively you can just start a build via Build with parameters and check the forceNativeBuild box

Yes but this only works for committers and especially when testing different approaches it is a bit inconvenient, but of course many things work (including replay).

Yes that's right. I just wanted to show an alternative that IMO suitable if one just wants try a change only ones or twice.

Is this still in the draft state? Would be great to have it before M3.

@jonahgraham said in #1795 (comment) that he want's to enhance this a bit further but in general this looks good to me and I assume we can land this very soon (after the commits have been squashed). One can already test the built native fragments from:
https://ci.eclipse.org/releng/job/eclipse.platform.swt/view/change-requests/job/PR-1795/13/

[jonahgraham]

Is this still in the draft state? Would be great to have it before M3.

I hope it is completely ready for review very soon, well before M3. I have just pushed a squashed version that also includes the checking of dependencies. Assuming it builds correctly I will mark as ready for review soon.

I did some restructuring compared to the previous commit. The force-pushed compare link renders those changes well.

---

The updated commit message is:

Build GTK3 support for linux x86-64 to maximize compatibility

Recently all SWT builds for Linux x86-64 have been done on a new Debian image. This leads to requiring such a new distro to be able to run SWT successfully.

This change builds GTK3 and common code on an older debian container to increase the range of versions we support. Only GTK4's key library, libswt-pi4-gtk*.so is shipped from a build on the new debian container.

We continue to build all of the natives on latest debian so we benefit from compiler warnings/errors and other such tooling.

As part of the build all .so files are checked to ensure their dependencies are as expected. In particular glibc version is checked for all symbols and all libraries are checked.

The version of glibc 2.14 was chosen as that is what the effective requirement has been for a while for SWT (at least since Eclipse 4.26/2022-12)

Fixes #1791

[jonahgraham]

I have verified that the build contains the correct info and I open this up as Ready for review.

gtk3 + gtk4 build output

Key parts extracted from https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/PR-1795/14/pipeline-console/

gtk4

16:54:08  Verifying libswt-gtk-4968r9.so libswt-awt-gtk-4968r9.so libswt-pi4-gtk-4968r9.so libswt-cairo-gtk-4968r9.so libswt-atk-gtk-4968r9.so libswt-glx-gtk-4968r9.so libswt-webkit-gtk-4968r9.so have permitted dependencies
16:54:08  ./check_dependencies.sh libswt-gtk-4968r9.so 2.34 libc.so.6 libpthread.so.0 libdl.so.2 libm.so.6
16:54:08  ./check_dependencies.sh libswt-awt-gtk-4968r9.so 2.34 libc.so.6 libpthread.so.0 libdl.so.2 libm.so.6 libjawt.so
16:54:08  ./check_dependencies.sh libswt-pi4-gtk-4968r9.so 2.34 libc.so.6 libpthread.so.0 libdl.so.2 libm.so.6 libgtk-4.so.1
16:54:08  ./check_dependencies.sh libswt-cairo-gtk-4968r9.so 2.34 libc.so.6 libpthread.so.0 libdl.so.2 libm.so.6 libcairo.so.2
16:54:08  ./check_dependencies.sh libswt-atk-gtk-4968r9.so 2.34 libc.so.6 libpthread.so.0 libdl.so.2 libm.so.6 libatk-1.0.so.0
16:54:08  ./check_dependencies.sh libswt-glx-gtk-4968r9.so 2.34 libc.so.6 libpthread.so.0 libdl.so.2 libm.so.6 libGL.so.1 libGLU.so.1
16:54:08  ./check_dependencies.sh libswt-webkit-gtk-4968r9.so 2.34 libc.so.6 libpthread.so.0 libdl.so.2 libm.so.6 libgio-2.0.so.0 libgobject-2.0.so.0 libglib-2.0.so.0
16:54:08  cp libswt-pi4-gtk-4968r9.so /home/jenkins/agent/workspace/eclipse.platform.swt_PR-1795/libs
16:54:08  -e GTK4 Build succeeded

gtk3

16:53:48  Verifying libswt-gtk-4968r9.so libswt-awt-gtk-4968r9.so libswt-pi3-gtk-4968r9.so libswt-cairo-gtk-4968r9.so libswt-atk-gtk-4968r9.so libswt-glx-gtk-4968r9.so libswt-webkit-gtk-4968r9.so have permitted dependencies
16:53:48  ./check_dependencies.sh libswt-gtk-4968r9.so 2.14 libc.so.6 libpthread.so.0 libdl.so.2 libm.so.6
16:53:48  ./check_dependencies.sh libswt-awt-gtk-4968r9.so 2.14 libc.so.6 libpthread.so.0 libdl.so.2 libm.so.6 libjawt.so
16:53:48  ./check_dependencies.sh libswt-pi3-gtk-4968r9.so 2.14 libc.so.6 libpthread.so.0 libdl.so.2 libm.so.6 libgtk-3.so.0 libgdk-3.so.0 libcairo.so.2 libgthread-2.0.so.0
16:53:48  ./check_dependencies.sh libswt-cairo-gtk-4968r9.so 2.14 libc.so.6 libpthread.so.0 libdl.so.2 libm.so.6 libcairo.so.2
16:53:48  ./check_dependencies.sh libswt-atk-gtk-4968r9.so 2.14 libc.so.6 libpthread.so.0 libdl.so.2 libm.so.6 libatk-1.0.so.0
16:53:48  ./check_dependencies.sh libswt-glx-gtk-4968r9.so 2.14 libc.so.6 libpthread.so.0 libdl.so.2 libm.so.6 libGL.so.1 libGLU.so.1
16:53:[48](https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/PR-1795/14/pipeline-console/?start-byte=0&selected-node=680#log-48)  ./check_dependencies.sh libswt-webkit-gtk-4968r9.so 2.14 libc.so.6 libpthread.so.0 libdl.so.2 libm.so.6 libgio-2.0.so.0 libgobject-2.0.so.0 libglib-2.0.so.0
16:53:48  cp libswt-gtk-[49](https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/PR-1795/14/pipeline-console/?start-byte=0&selected-node=680#log-49)68r9.so libswt-awt-gtk-4968r9.so libswt-pi3-gtk-4968r9.so libswt-cairo-gtk-4968r9.so libswt-atk-gtk-4968r9.so libswt-glx-gtk-4968r9.so libswt-webkit-gtk-4968r9.so /home/jenkins/agent/workspace/eclipse.platform.swt_PR-1795/libs
16:53:48  -e GTK3 Build succeeded

As you can see from the above build output

• we are checking all the dependency versions as expected
• now on gtk4 only the unique gtk4 libs are copied to the libs/ to be stashed.

---

To verify that the produced build worked as expected this is what I did on an Xubuntu 24.04 machine

1. Download https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/PR-1795/lastSuccessfulBuild/artifact/eclipse.platform.swt/binaries/org.eclipse.swt.gtk.linux.x86_64/target/org.eclipse.swt.gtk.linux.x86_64-3.129.0-SNAPSHOT.jar
2. Create SWT dev env with Oomph
3. Run some snippets + Eclipse Application from within the IDE both with SWT_GTK4 set to 1 and not

• to verify we are starting from expected before state

4. With Snippet1 launch config, press Show Command Line
5. Run that command from a shell
6. Run that command from a shell under x11docker by prefixing it with x11docker --share /scratch x11docker/xfce --

• this should error with /lib/x86_64-linux-gnu/libc.so.6: version GLIBC_2.34 not found

7. Repeat 4-6, but for the full Eclipse Application
8. cd git/eclipse.platform.swt/binaries/org.eclipse.swt.gtk.linux.x86_64
9. rm *.so
10. unzip ~/Downloads/org.eclipse.swt.gtk.linux.x86_64-3.129.0-SNAPSHOT.jar '*.so'
11. Update org.eclipse.swt.internal.Library.REVISION to 9
12. Run some snippets + Eclipse IDE from within the IDE

• this should verify everything still works on recent distro

13. Re-run the step 6 again and the snippet should open on the x11docker/xfce which uses the older version of Debian
14. Re-run the step 7 again and the Eclipse Application should open on the x11docker/xfce which uses the older version of Debian

The --share /scratch works for my setup because my JDK and my eclipse install is all located under /scratch. Additional directories may need to be shared with x11docker if your JDK is elsewhere.

This is the full command I used in step 7 + 14:

x11docker --share /scratch x11docker/xfce --  /scratch/java/jdk-21.0.5+11/bin/java -Dorg.eclipse.swt.graphics.Resource.reportNonDisposed=true -Declipse.pde.launch=true --add-modules=ALL-SYSTEM -Djava.security.manager=allow -Dfile.encoding=UTF-8 -Dstdout.encoding=UTF-8 -Dstderr.encoding=UTF-8 -classpath /scratch/eclipse/oomph/swt-master/git/equinox/bundles/org.eclipse.equinox.launcher/bin: -XX:+ShowCodeDetailsInExceptionMessages org.eclipse.equinox.launcher.Main -launcher /scratch/eclipse/oomph/swt-master/ws/.metadata/.plugins/org.eclipse.pde.core/.install_folders/1738530644995/eclipse -name Eclipse -showsplash 600 -product org.eclipse.sdk.ide -data /scratch/eclipse/oomph/swt-master/ws/../runtime-New_configuration -configuration file:///scratch/eclipse/oomph/swt-master/ws/.metadata/.plugins/org.eclipse.pde.core/New_configuration/ -dev file:///scratch/eclipse/oomph/swt-master/ws/.metadata/.plugins/org.eclipse.pde.core/New_configuration/dev.properties -os linux -ws gtk -arch x86_64 -nl en_US -consoleLog

[HannesWell]

Thanks for the update, the change looks good to me.
I just have a remark about a small readability improvement that gave me hard time to understand the change. Please see below.

I have also verified that all so-files in the linux.x86_64 fragment except for libswt-pi4-gtk-*.so only reference GLIBC_ 2.14 or below.

[HannesWell]

I just have a remark about a small readability improvement that gave me hard time to understand the change. Please see below.

@jonahgraham I have just pushed a commit that includes the suggested change to your branch. If you are fine with it, please squash it into your commit and I would perfectly fine with this.

[jonahgraham]

I just have a remark about a small readability improvement that gave me hard time to understand the change. Please see below.

@jonahgraham I have just pushed a commit that includes the suggested change to your branch. If you are fine with it, please squash it into your commit and I would perfectly fine with this.

I like the change - I'll squash and push momentarily.

[HannesWell]

I like the change - I'll squash and push momentarily.

Great and thank you for this change!

[HannesWell]

The master build successfully rebuilt the native libraries and tonights I-build will contain it.

[iloveeclipse]

The master build successfully rebuilt the native libraries and tonights I-build will contain it.

Just in time for my Friday's weekly product build on latest SDK nightly that will run on RHEL7 & 9.

[tjwatson]

Thanks for all the focus on this issue. Glad it got done for this release!

[jonahgraham]

🥳 The I-build works

I tested this change + the corresponding change eclipse-equinox/equinox#834 with I20250206-1800. The test suites have not completed running yet. While the SWT unit tests passed in this PR, please help me identify if anything looks like it regressed in the integration build.

Prep steps

Completed on my Xubuntu 24.04 machine:

1. Download eclipse-platform-I20250206-1800-linux-gtk-x86_64.tar.gz from https://download.eclipse.org/eclipse/downloads/drops4/I20250206-1800/
2. mkdir -p /tmp/I20250206-1800 && cd /tmp/I20250206-1800
3. tar xf ~/Downloads/*I20250206-1800*
4. JAVA_HOME=/scratch/java/jdk-21.0.5+11

On that Eclipse, I ran each of the following commands and verified that Eclipse started as expected:

GTK3 runs

Runs on Xubuntu 24.04:

• $PWD/eclipse/eclipse -data data -consoleLog -nosplash -vm $JAVA_HOME/bin/java
• $PWD/eclipse/eclipse -data data -consoleLog -nosplash -vm $JAVA_HOME/lib/server/libjvm.so

Runs on Debian 11 - these are the commands that were failing without this fix:

• x11docker --share $JAVA_HOME --share $PWD x11docker/xfce -- $PWD/eclipse/eclipse -data data -consoleLog -nosplash -vm $JAVA_HOME/bin/java
• x11docker --share $JAVA_HOME --share $PWD x11docker/xfce -- $PWD/eclipse/eclipse -data data -consoleLog -nosplash -vm $JAVA_HOME/lib/server/libjvm.so

SWT_GTK4=1 runs with gtk4 installed

• SWT_GTK4=1 $PWD/eclipse/eclipse -data data -consoleLog -nosplash -vm $JAVA_HOME/bin/java
• SWT_GTK4=1 $PWD/eclipse/eclipse -data data -consoleLog -nosplash -vm $JAVA_HOME/lib/server/libjvm.so

SWT_GTK4=1 runs without gtk4 installed

I see the expected error in log: SWT OS.java Error: Failed to load swt-pi4, loading swt-pi3 as fallback. then gtk3 gui loads successfully

• x11docker --share $JAVA_HOME --share $PWD --env SWT_GTK4=1 x11docker/xfce -- $PWD/eclipse/eclipse -data data -consoleLog -nosplash -vm $JAVA_HOME/bin/java
• x11docker --share $JAVA_HOME --share $PWD --env SWT_GTK4=1 x11docker/xfce -- $PWD/eclipse/eclipse -data data -consoleLog -nosplash -vm $JAVA_HOME/lib/server/libjvm.so

java and libjvm.so tested

Note that the above includes starting eclipse with both sub-process JVM and lib JVM, which is more relevant to the change I made in equinox than SWT, but included here for completeness.

For clarity for those that don't know, the sub-process JVM (-vm $JAVA_HOME/bin/java) gives a process tree that looks a little like this:

UID          PID    PPID  C STIME TTY          TIME CMD
jonah    1790246    4084  0 10:21 pts/36   00:00:01 bash
jonah    1844920 1790246  0 20:26 pts/36   00:00:00   /tmp/I20250206-1800/eclipse/eclipse -data data -consoleLog -nosplash -vm /scratch/java/jdk-21.0.5+11/bin/java
jonah    1844944 1844920 24 20:26 pts/36   00:00:12     /scratch/java/jdk-21.0.5+11/bin/java -Dosgi.requiredJavaVersion=21 -Dosgi.dataAreaRequiresExplicitInit=true -Dorg.eclipse.swt.graphics.Resource.reportNonDisposed=true --add-m --snip--
jonah    1845014 1844944  0 20:26 pts/36   00:00:00       /usr/lib/x86_64-linux-gnu/webkit2gtk-4.1/WebKitNetworkProcess 8 146 148
jonah    1845015 1844944  0 20:26 pts/36   00:00:00       /usr/lib/x86_64-linux-gnu/webkit2gtk-4.1/WebKitWebProcess 13 148 151

While lib JVM (-vm $JAVA_HOME/lib/server/libjvm.so) looks like this:

jonah    1790246    4084  0 10:21 pts/36   00:00:01 bash
jonah    1845186 1790246 99 20:27 pts/36   00:00:10   /tmp/I20250206-1800/eclipse/eclipse -data data -consoleLog -nosplash -vm /scratch/java/jdk-21.0.5+11/lib/server/libjvm.so
jonah    1845265 1845186  2 20:27 pts/36   00:00:00     /usr/lib/x86_64-linux-gnu/webkit2gtk-4.1/WebKitNetworkProcess 8 146 149
jonah    1845266 1845186 10 20:27 pts/36   00:00:00     /usr/lib/x86_64-linux-gnu/webkit2gtk-4.1/WebKitWebProcess 13 148 151

[iloveeclipse]

I fear there was a problem with the build of the binaries / lfs.

I can't pull from master locally, I see git lfs errors like

eclipse.platform.swt$ git pull eclipse master
From https://github.com/eclipse-platform/eclipse.platform.swt
 * branch                  master     -> FETCH_HEAD
Updating 54dad6ce30..9a9cf3184f
Downloading binaries/org.eclipse.swt.cocoa.macosx.aarch64/libswt-awt-cocoa-4968r9.jnilib (52 KB)
Error downloading object: binaries/org.eclipse.swt.cocoa.macosx.aarch64/libswt-awt-cocoa-4968r9.jnilib (bfd3fdd): Smudge error: Error downloading binaries/org.eclipse.swt.cocoa.macosx.aarch64/libswt-awt-cocoa-4968r9.jnilib (bfd3fdd9533110fbdfc270f83dab8daf993f9e5e201e7a734a8cd3af30e76ddf): [bfd3fdd9533110fbdfc270f83dab8daf993f9e5e201e7a734a8cd3af30e76ddf] Object does not exist on the server: [404] Object does not exist on the server

Errors logged to '/data/4x_platform/eclipse.platform.releng.aggregator/.git/modules/eclipse.platform.swt/lfs/logs/20250207T072755.284594602.log'.
Use `git lfs logs last` to view the log.
error: external filter 'git-lfs filter-process' failed
fatal: binaries/org.eclipse.swt.cocoa.macosx.aarch64/libswt-awt-cocoa-4968r9.jnilib: smudge filter lfs failed

I also don't see build results for anything but Linux on https://download.eclipse.org/eclipse/downloads/drops4/I20250206-1800/

[iloveeclipse]

OK, that is strange. I was able to pull from master from RH9 but not from RH7. After pulling / pushing to local RH9 repo I was able to pull from local on RH7.

[HannesWell]

🥳 The I-build works

Awesome. I can also test it next Wednesday on a Linux workstation.

I also don't see build results for anything but Linux on https://download.eclipse.org/eclipse/downloads/drops4/I20250206-1800/

They are still running: https://ci.eclipse.org/releng/job/AutomatedTests/
The Y-build yesterday seems to have hang for 4h in the Gather Eclipse Parts stage and therefore it's tests correspondingly started later. However also the I-build tests seems to have a pause period of an hour (at least on Windows). After a quick look I didn't found a specific reason. Maybe some maintenance was done in the background. I suggest we wait and see how the situation is next time.

[iloveeclipse]

OK, that is strange. I was able to pull from master from RH9 but not from RH7. After pulling / pushing to local RH9 repo I was able to pull from local on RH7.

On RH7 I have git version 2.36.5, on RH9 2.39.2.3, so they seem to have fixed something in git...

I was able to build platform on RH7 now & start IDE. Test results follow, but I believe we should be fine regarding older GLIBC now.

Many thanks Jonah, Hannes & everyone involved!

[tjwatson]

I can confirm the latest I-Build now runs on my RHEL 8 development environment. Thanks!