Don't install libomp aliases by default in LLVM easyblock

[Flamefire]

As discussed in
easybuilders/easybuild-framework#4535 it could lead to issues caused by incompatible libraries used by different compilers. Especially GCC and LLVM/Clang picking up the wrong libomp vs libgomp.

See also #3755 (comment) & #3815 (comment)

This restores the behavior changed by #3815 but adds an option to enable them (off by default). This is useful/required for Clang easyconfigs using this easyblock as otherwise there would be a difference compared to using the Clang easyblock. See #3755 (comment)

I used build_openmp_library_aliases as the option name to group it nicely with the other OMP options, although "install" is more correct.

As there now is a new check for an incompatible combination of options dependent on OpenMP I combined them into a single place and error with correct exit code.

I also made the use of OFF/ON in the CMake arguments consistent as I had to look up whether the checks are case sensitive or not. They are not, so the change is only cosmetic but avoids further confusion.

cc @Thyre @Crivella

[Crivella]

I am fine with it being optional, but i still do not think that having it on Clang==18.1.8 will be ideal as it might cause trouble when Clang is loaded together with other stuff that was compiled with GCCcore + libgomp

[Flamefire]

I am fine with it being optional, but i still do not think that having it on Clang==18.1.8 will be ideal as it might cause trouble when Clang is loaded together with other stuff that was compiled with GCCcore + libgomp

IMO that is a separate issue: If we don't do that while moving the (existing) Clang easyconfigs to this easyblock we'd change the resulting installation which I'd avoid.
If that was causing issues, it wasn't noticed or at least not reported so far.

[ocaisa]

I would agree with @Flamefire here, we shouldn't change existing behaviour unless we see a problem in real life.

The thing is, we don't really know if this problem exists for our existing recipes. The best thing to do would be to scan the jsc-zen3 GCCcore-based installations and see if there are examples of linking against libgomp, at least there you know you have almost all easyconfigs installed.

I expect the number of cases to be very small. Even in the cases where it does exist, it may be better to turn OpenMP off rather than switch toolchain to GCC.

[Thyre]

I would agree with @Flamefire here, we shouldn't change existing behaviour unless we see a problem in real life.

The thing is, we don't really know if this problem exists for our existing recipes. The best thing to do would be to scan the jsc-zen3 GCCcore-based installations and see if there are examples of linking against libgomp, at least there you know you have almost all easyconfigs installed.

I expect the number of cases to be very small. Even in the cases where it does exist, it may be better to turn OpenMP off rather than switch toolchain to GCC.

I tried to gather a few results here: easybuilders/easybuild-framework#4535 (comment)
This generally matches your expectations. Only a few cases use OpenMP, and even then it might only be used for some testing e.g.
It doesn't include all our software, especially since we started testing quite a few EasyConfigs with --installpath=/tmp/[...], but should give us a good (first) idea...

[boegel]

Ship has sailed on EasyBuild v5.1.1, so this will have to wait until release after that (likely end of August)

[Flamefire]

Uff. That means we did introduce a behavior change that might affect users although analysis seems not fully conclusive.

[Thyre]

Uff. That means we did introduce a behavior change that might affect users although analysis seems not fully conclusive.

I don't see this as a huge deal-breaker, as we had this situation with Clang for a long time (and Intel compilers as well IIRC).

We didn't get a complaint, so fixing this finally in EasyBuild 5.1.1-next looks fine for me.

[Flamefire]

Should we then change the default here to True to not introduce another change with the next release?

[Flamefire]

Test report by @Flamefire

Overview of tested easyconfigs (in order)

• SUCCESS LLVM-19.1.7-GCCcore-13.3.0.eb
• SUCCESS LLVM-20.1.5-GCCcore-13.3.0.eb
• FAIL (build issue) LLVM-18.1.8-GCCcore-13.3.0.eb (partial log available at https://gist.github.com/Flamefire/bf56682dc97d32a1511b65588736c7a2)

Build succeeded for 2 out of 3 (3 easyconfigs in total)
n1711 - Linux RHEL 8.9 (Ootpa), x86_64, Intel(R) Xeon(R) Platinum 8470 (sapphirerapids), Python 3.9.18
See https://gist.github.com/Flamefire/a415043d30e45305afe71a12a1384a39 for a full test report.

[Flamefire]

Test report by @Flamefire

Overview of tested easyconfigs (in order)

• SUCCESS LLVM-19.1.7-GCCcore-13.3.0.eb
• SUCCESS LLVM-20.1.5-GCCcore-13.3.0.eb
• SUCCESS LLVM-18.1.8-GCCcore-13.3.0.eb

Build succeeded for 3 out of 3 (3 easyconfigs in total)
c128 - Linux AlmaLinux 9.4, x86_64, AMD EPYC 9334 32-Core Processor (zen4), 4 x NVIDIA NVIDIA H100, 560.35.03, Python 3.9.18
See https://gist.github.com/Flamefire/e281a3d504d7929951e24838147c5c2e for a full test report.

[Crivella]

Should we then change the default here to True to not introduce another change with the next release?

We would still have to switch the ECs to have False afterward.
Both ways will result in people having to rebuild anyway (unless they want to manually delete the symlinks)

I would leave the default to False

[Flamefire]

We would still have to switch the ECs to have False afterward.

I meant:

• Current behavior: No symlinks installed
• 5.1.1 behavior: symlinks installed
• 5.1.2 behavior with this PR merged: no symlinks installed.

So we have 2 changes without changes to the (ours and users) easyconfigs. Either we merge this for 5.1.1 and keep the no-symlinks-behavior without any changes over the versions or we merge this for 5.1.2 but change the default to True so there is only 1 change from now to 5.1.1 but none from 5.1.1 to 5.1.2

[Flamefire]

Test report by @Flamefire

Overview of tested easyconfigs (in order)

• SUCCESS LLVM-19.1.7-GCCcore-13.3.0.eb
• SUCCESS LLVM-20.1.5-GCCcore-13.3.0.eb
• SUCCESS LLVM-18.1.8-GCCcore-13.3.0.eb

Build succeeded for 3 out of 3 (3 easyconfigs in total)
i7007 - Linux Rocky Linux 8.9 (Green Obsidian), x86_64, AMD EPYC 7702 64-Core Processor (zen2), Python 3.9.18
See https://gist.github.com/Flamefire/e7bf7b4d6e7ddbc09a15c2dfef598fa1 for a full test report.

[Crivella]

@boegelbot please test @ jsc-zen3
EB_ARGS="LLVM-18.1.8-GCCcore-13.3.0.eb LLVM-19.1.7-GCCcore-13.3.0.eb LLVM-20.1.5-GCCcore-13.3.0.eb"
CORE_CNT=16

[boegelbot]

@Crivella: 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=3825 EB_ARGS="LLVM-18.1.8-GCCcore-13.3.0.eb LLVM-19.1.7-GCCcore-13.3.0.eb LLVM-20.1.5-GCCcore-13.3.0.eb" EB_REPO=easybuild-easyblocks EB_BRANCH=develop /opt/software/slurm/bin/sbatch --job-name test_PR_3825 --ntasks="16" ~/boegelbot/eb_from_pr_upload_jsc-zen3.sh' executed!

• exit code: 0
• output:

Submitted batch job 7162

Test results coming soon (I hope)...

- notification for comment with ID 3043921119 processed

Message to humans: this is just bookkeeping information for me,
it is of no use to you (unless you think I have a bug, which I don't).

[boegelbot]

Test report by @boegelbot

Overview of tested easyconfigs (in order)

• SUCCESS LLVM-18.1.8-GCCcore-13.3.0.eb
• SUCCESS LLVM-19.1.7-GCCcore-13.3.0.eb
• SUCCESS LLVM-20.1.5-GCCcore-13.3.0.eb

Build succeeded for 3 out of 3 (3 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/47dd30e3aae2b1fe58a2f52b06b2941e for a full test report.

[Crivella]

LGTM

[Crivella]

Going in, thanks @Flamefire!