@jhgoebbert, can you take a quick look at this PR? You've added the EasyConfig to our JSC repo last stage.
I basically just bumped all the versions, where possible.

@Crivella, this is another EC which will pull in a "special" LLVM version. Should we add an explicit conflict to LLVM, especially as there will be conflicting binaries in $EBROOTCLING/bin and shared libraries in $EBROOTCLING/lib?

Test report by @Thyre
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in total)
Linux - Linux Arch Linux UNKNOWN, x86_64, AMD Ryzen 7 7800X3D 8-Core Processor, 1 x AMD Navi 48 [Radeon RX 9070/9070 XT/9070 GRE] (device id: 0x7550, gfx: gfx1201, driver: 6.15.5-arch1-1), 1 x AMD Raphael (device id: 0x164e, gfx: gfx1036, driver: 6.15.5-arch1-1), Python 3.13.5
See https://gist.github.com/Thyre/32a0701e34e1be10414d6835cbe2add8 for a full test report.

Might need some more work, e.g. for picking up the GCC correctly.
The LLVM EasyBlock probably won't work due to the reliance on version.

Maybe one can work around this with a Bundle, even though that's more of a hack than a proper solution?

Yeah i think we should try to find a way to handle all the packages that brings their own version of LLVM. If it is just libraries and statically linked we might get around it, but if they bring the shared objects or the binaries we definitely need a way around it

Test report by @Thyre
FAILED
Build succeeded for 0 out of 1 (1 easyconfigs in total)
Linux - Linux Arch Linux UNKNOWN, x86_64, AMD Ryzen 7 7800X3D 8-Core Processor, 1 x AMD Navi 48 [Radeon RX 9070/9070 XT/9070 GRE] (device id: 0x7550, gfx: gfx1201, driver: 6.15.5-arch1-1), 1 x AMD Raphael (device id: 0x164e, gfx: gfx1036, driver: 6.15.5-arch1-1), Python 3.13.5
See https://gist.github.com/Thyre/d35ce510a8e83c82f90a66dd82f32e4e for a full test report.

Test report by @Thyre
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in total)
Linux - Linux Arch Linux UNKNOWN, x86_64, AMD Ryzen 7 7800X3D 8-Core Processor, 1 x AMD Navi 48 [Radeon RX 9070/9070 XT/9070 GRE] (device id: 0x7550, gfx: gfx1201, driver: 6.15.5-arch1-1), 1 x AMD Raphael (device id: 0x164e, gfx: gfx1036, driver: 6.15.5-arch1-1), Python 3.13.5
See https://gist.github.com/Thyre/53f5888b4cdbf28f0f037731f7818651 for a full test report.

@boegelbot please test @ jsc-zen3

@Thyre: Request for testing this PR well received on jsczen3l1.int.jsc-zen3.fz-juelich.de

PR test command 'if [[ develop != 'develop' ]]; then EB_BRANCH=develop ./easybuild_develop.sh 2> /dev/null 1>&2; EB_PREFIX=/home/boegelbot/easybuild/develop source init_env_easybuild_develop.sh; fi; EB_PR=23388 EB_ARGS= EB_CONTAINER= EB_REPO=easybuild-easyconfigs EB_BRANCH=develop /opt/software/slurm/bin/sbatch --job-name test_PR_23388 --ntasks=8 ~/boegelbot/eb_from_pr_upload_jsc-zen3.sh' executed!

• exit code: 0
• output:

Submitted batch job 7226

Test results coming soon (I hope)...

Test report by @boegelbot
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in total)
jsczen3c1.int.jsc-zen3.fz-juelich.de - Linux Rocky Linux 9.5, x86_64, AMD EPYC-Milan Processor (zen3), Python 3.9.21
See https://gist.github.com/boegelbot/21e78dd1eeec1de5a35aa2c61fbdd03b for a full test report.

Test report by @Thyre
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in total)
datenlager - Linux Ubuntu 24.04, x86_64, AMD Ryzen 7 3700X 8-Core Processor, Python 3.12.3
See https://gist.github.com/Thyre/75bee334ece9bbc6d661239ec8b6a54b for a full test report.

Is the LLVM used here a customized version like for RUST or is it just pinned to some version?
I was wondering if it would be worth trying to build this on top of an existing LLVM, instead of bringing its own.

This would also allow having LLVM as a dependency which would partially solve the problem of avoiding clashes with other libLLVM.so (or atleast get a warning from Lmod when you replace version of LLVM)

Is the LLVM used here a customized version like for RUST or is it just pinned to some version?

I was wondering if it would be worth trying to build this on top of an existing LLVM, instead of bringing its own.

This would also allow having LLVM as a dependency which would partially solve the problem of avoiding clashes with other libLLVM.so (or atleast get a warning from Lmod when you replace version of LLVM)

Given that they tagged LLVM 18 multiple times (with a date versionsuffix), and that I've seen API changes between these tags, I unfortunately expect that this is a custom fork 😞

I'll cross-check though. Maybe the changes are small enough.

The good thing is though, this only ships static LLVM libraries, and no llvm-config.
The only issue really is clang/clang++ as executables, and the libclang-cpp.so, which unfortunately doesn't have a version suffix.

Here's the diff of LLVM 18.1.8 vs Cling's LLVM:
Cling-diffs.txt

It's honestly less than I would've expected, but still some parts which are clearly not compatible unfortunately. And even it they would somewhat match, we would need to provide LLVM 18 in 2025b as well.

Test report by @Thyre
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in total)
ZAM054 - Linux Zorin OS 17, x86_64, 12th Gen Intel(R) Core(TM) i7-1260P, 1 x NVIDIA NVIDIA GeForce MX550, 570.133.07, Python 3.10.12
See https://gist.github.com/Thyre/bcf1bc786af9f70c839e5e090790c1e7 for a full test report.

Test report by @Crivella
SUCCESS
Build succeeded for 4 out of 4 (1 easyconfigs in total)
crivella-desktop - Linux Ubuntu 22.04.5 LTS (Jammy Jellyfish), x86_64, 13th Gen Intel(R) Core(TM) i9-13900K (skylake), Python 3.11.13
See https://gist.github.com/Crivella/b54b8b9088e300b9e86715a5617ddaf1 for a full test report.

Going in, thanks @Thyre!