{lang}[GCCcore/13.2.0] Java-awtlibs v17.0.6

[casparvl]

(created using eb --new-pr)

• depends on Restructure RPATH and elf interpreter setting for Java, and add the LIBRARY_PATH to the additional RPATH and separate java awt libs easybuild-easyblocks#3583

This is a result of the discussion in #22245 (comment)

TLDR:

Java has some libraries that use X11 and alsa-libs. They can only be RPATH-ed with the new EasyBlock changes from easybuilders/easybuild-easyblocks#3583 if the necessary dependencies (X11 and alsa-libs) are listed, but those deps are at GCCcore level. Pushing Java to GCCcore level has substantial implications, and is something we want to avoid (for now).

Instead, we came up with the solution to separate out the libraries that depend on X11 and alsa-libs (fortunately, it is a separable set). That's done by stripping these libs from the regular Java installation (done by default by the changes in depends on easybuilders/easybuild-easyblocks#3583 ) and by installing them with the Java-awtlibs easyconfig.

This allows us to then include Java-awtlibs only in Java applications that require the use of the AWT libraries. That also means that only those applications will have to be pushed to the GCCcore toolchain level, substantially limiting the impact of this change.

To test:

Rebuild your local Java with easybuilders/easybuild-easyblocks#3583 (and --rpath, if you want to test that part). Then, build Java-awtlibs with easybuilders/easybuild-easyblocks#3583 and #22280 (and --rpath). Note that I had to not only do --include-easyblocks for this, but also add the Java EasyBlock to the PYTHONPATH (otherwise, self.AWT_LIBS wasn't defined for the Java_minus_awtlibs easyblock).

Building like this now gives me:

[casparl@tcn1 java_gcccore]$ readelf -a /scratch-nvme/1/casparl/generic/software/Java-awtlibs/17.0.6-GCCcore-13.2.0/lib/libawt.so | grep RPATH

 0x000000000000000f (RPATH)              Library rpath: [$ORIGIN:/scratch-nvme/1/casparl/generic/software/Java/17.0.6/lib/server:/scratch-nvme/1/casparl/generic/software/Java/17.0.6/lib]
[casparl@tcn1 java_gcccore]$ readelf -a /scratch-nvme/1/casparl/generic/software/Java-awtlibs/17.0.6-GCCcore-13.2.0/lib/libawt_xawt.so | grep RPATH
 0x000000000000000f (RPATH)              Library rpath: [$ORIGIN:/scratch-nvme/1/casparl/generic/software/Java/17.0.6/lib/server:/scratch-nvme/1/casparl/generic/software/X11/20231019-GCCcore-13.2.0/lib:/scratch-nvme/1/casparl/generic/software/Java/17.0.6/lib]
[casparl@tcn1 java_gcccore]$ ldd /scratch-nvme/1/casparl/generic/software/Java-awtlibs/17.0.6-GCCcore-13.2.0/lib/libawt.so
ldd: warning: you do not have execution permission for `/scratch-nvme/1/casparl/generic/software/Java-awtlibs/17.0.6-GCCcore-13.2.0/lib/libawt.so'
        linux-vdso.so.1 (0x00007ffe493a9000)
        libjvm.so => /scratch-nvme/1/casparl/generic/software/Java/17.0.6/lib/server/libjvm.so (0x000014567ae2d000)
        libjava.so => /scratch-nvme/1/casparl/generic/software/Java/17.0.6/lib/libjava.so (0x000014567adff000)
        libm.so.6 => /lib64/libm.so.6 (0x000014567ad12000)
        libdl.so.2 => /lib64/libdl.so.2 (0x000014567ad0d000)
        libc.so.6 => /lib64/libc.so.6 (0x000014567ab04000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x000014567aafd000)
        librt.so.1 => /lib64/librt.so.1 (0x000014567aaf8000)
        /lib64/ld-linux-x86-64.so.2 (0x000014567c26b000)
[casparl@tcn1 java_gcccore]$ ldd /scratch-nvme/1/casparl/generic/software/Java-awtlibs/17.0.6-GCCcore-13.2.0/lib/libawt_xawt.so
ldd: warning: you do not have execution permission for `/scratch-nvme/1/casparl/generic/software/Java-awtlibs/17.0.6-GCCcore-13.2.0/lib/libawt_xawt.so'
        linux-vdso.so.1 (0x00007ffd6fdb8000)
        libm.so.6 => /lib64/libm.so.6 (0x0000153c18006000)
        libawt.so => /scratch-nvme/1/casparl/generic/software/Java-awtlibs/17.0.6-GCCcore-13.2.0/lib/libawt.so (0x0000153c17f10000)
        libXext.so.6 => /scratch-nvme/1/casparl/generic/software/X11/20231019-GCCcore-13.2.0/lib/libXext.so.6 (0x0000153c17ef7000)
        libX11.so.6 => /scratch-nvme/1/casparl/generic/software/X11/20231019-GCCcore-13.2.0/lib/libX11.so.6 (0x0000153c17d73000)
        libXrender.so.1 => /scratch-nvme/1/casparl/generic/software/X11/20231019-GCCcore-13.2.0/lib/libXrender.so.1 (0x0000153c17d62000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000153c17d5d000)
        libXtst.so.6 => /scratch-nvme/1/casparl/generic/software/X11/20231019-GCCcore-13.2.0/lib/libXtst.so.6 (0x0000153c17d54000)
        libXi.so.6 => /scratch-nvme/1/casparl/generic/software/X11/20231019-GCCcore-13.2.0/lib/libXi.so.6 (0x0000153c17d3c000)
        libjava.so => /scratch-nvme/1/casparl/generic/software/Java/17.0.6/lib/libjava.so (0x0000153c17d0e000)
        libjvm.so => /scratch-nvme/1/casparl/generic/software/Java/17.0.6/lib/server/libjvm.so (0x0000153c169c8000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x0000153c169c1000)
        libc.so.6 => /lib64/libc.so.6 (0x0000153c167b8000)
        /lib64/ld-linux-x86-64.so.2 (0x0000153c18161000)
        libxcb.so.1 => /scratch-nvme/1/casparl/generic/software/X11/20231019-GCCcore-13.2.0/lib/libxcb.so.1 (0x0000153c16786000)
        librt.so.1 => /lib64/librt.so.1 (0x0000153c16781000)
        libXau.so.6 => /scratch-nvme/1/casparl/generic/software/X11/20231019-GCCcore-13.2.0/lib/libXau.so.6 (0x0000153c16778000)
        libXdmcp.so.6 => /scratch-nvme/1/casparl/generic/software/X11/20231019-GCCcore-13.2.0/lib/libXdmcp.so.6 (0x0000153c1676f000)

This is like expected:

• We see that e.g. libawt.so finds the correct libjvm.so (which is now in a different install prefix, $EBROOTJAVA) on it's RPATH
• We see that e.g. libawt_xawt.so has the $EBROOTX11/lib directory in it's RPATH and indeed finds it's X11 dependencies there

[Micket]

I'm not sure we to include libawt.so here; i think it's actaully independent of the backend (i.e. there is a X11 backend vs a possible future Wayland backend for AWT).
Technically, alsa part isn't really connected to AWT at all i think, but that's probably fine to sneak this in.

But I have one concern, how will things play out when Java-17.eb moves on to >17.0.6? Will we just have all those package conflicts anyway? I.e. say I have;

# in .modulerc
module_version("Java/17.0.13", "17")

On a side-note, we will soon have 17.0.13 so merged so we should probably at least go for that here as well.

[casparvl]

I'm not sure we to include libawt.so here; i think it's actaully independent of the backend (i.e. there is a X11 backend vs a possible future Wayland backend for AWT).

I think you're right, there's no dep on X11, not sure why I put that in this list

[casparl@tcn1 java_gcccore]$ ldd /scratch-nvme/1/casparl/generic/software/Java-awtlibs/17.0.6-GCCcore-13.2.0/lib/libawt.so
ldd: warning: you do not have execution permission for `/scratch-nvme/1/casparl/generic/software/Java-awtlibs/17.0.6-GCCcore-13.2.0/lib/libawt.so'
        linux-vdso.so.1 (0x00007ffc945b6000)
        libjvm.so => /scratch-nvme/1/casparl/generic/software/Java/17.0.6/lib/server/libjvm.so (0x00001490aa304000)
        libjava.so => /scratch-nvme/1/casparl/generic/software/Java/17.0.6/lib/libjava.so (0x00001490aa2d6000)
        libm.so.6 => /lib64/libm.so.6 (0x00001490aa1e9000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00001490aa1e4000)
        libc.so.6 => /lib64/libc.so.6 (0x00001490a9fdb000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00001490a9fd4000)
        librt.so.1 => /lib64/librt.so.1 (0x00001490a9fcf000)
        /lib64/ld-linux-x86-64.so.2 (0x00001490ab742000)

Easy enough to change the AWT_LIBS list though. And yeah, the alsa stuff is technically not awt, but it felt overkill to capture that in yet another package...

But I have one concern, how will things play out when Java-17.eb moves on to >17.0.6? Will we just have all those package conflicts anyway?

Good question, I'll need to think about it. I guess we could setup something similar to Java for the Java-awtlibs, no? I.e.

# in .modulerc
module_version("Java/17.0.13", "17")
module_version("Java-awtlibs/17.0.13", "17")

? I mean, I think the goal would be that you'd still want to list a major version as a dependency, also for Java-awtlibs, so that you can update the min/revision version without recreating module files that depend on this, right?