Enhance AOCC EasyBlock to correctly pass GCC toolchain and compiler driver

[Thyre]

Recent AOCC versions saw changes in how the driver for compilation is detected. The AOCC EasyBlock uses wrappers right now, where the original compiler name is replaced with a wrapper calling [compiler].orig with the GCC toolchain.

However, with AOCC 4.2.0 and AOCC 5.0.0, I noticed that this breaks building C++ and Fortran codes. For C++, libstdc++ is not linked anymore. For Fortran, several libraries are missing.
To fix this, two things are implemented:

1. For clang and clang++, switch to the newer config files, which pass the argument. This is more robust than the wrapper script.
2. For flang, update the wrapper to override the flang.orig name with flang. This lets compilation work normally.

To ensure that everything works, checks for the GCC toolchain and compilation were added. The toolchain checks were taken from #3373, where similar things are checked.

[Thyre]

@SebastianAchilles, can you take a look at these changes? You've developed most of the EasyBlock.
@Crivella I reused parts of your LLVM PR (#3373) for the config file generation and sanity check. Is this okay for you? I can add you as a co-author if wanted.

[Thyre]

Test report by @Thyre

Overview of tested easyconfigs (in order)

• SUCCESS AOCC-4.0.0-GCCcore-12.2.0.eb

Build succeeded for 1 out of 1 (1 easyconfigs in total)
Linux - Linux EndeavourOS UNKNOWN, x86_64, AMD Ryzen 7 7800X3D 8-Core Processor, 1 x NVIDIA NVIDIA GeForce RTX 3070, 560.35.03, Python 3.12.7
See https://gist.github.com/Thyre/ddd69e55f9c2eb4951bc608eb712414e for a full test report.

[Thyre]

See easybuilders/easybuild-easyconfigs#21629 (comment) for AOCC 5.0.0

[Crivella]

@Thyre Fine by me, whatever you prefer.
Maybe if this are functions meant/needed to be used across multiple easyblocks i could try to generalize them so they can just be imported and used with the appropriate version checks

[Thyre]

@Thyre Fine by me, whatever you prefer. Maybe if this are functions meant/needed to be used across multiple easyblocks i could try to generalize them so they can just be imported and used with the appropriate version checks

@Crivella I think it would be a good idea, as similar sanity checks might be useful for other LLVM-based compilers (like AOCC, AOMP, oneAPI).

[Thyre]

Test report by @Thyre

Overview of tested easyconfigs (in order)

• SUCCESS AOCC-4.0.0-GCCcore-12.2.0.eb

Build succeeded for 1 out of 1 (1 easyconfigs in total)
Linux - Linux EndeavourOS UNKNOWN, x86_64, AMD Ryzen 7 7800X3D 8-Core Processor, 1 x NVIDIA NVIDIA GeForce RTX 3070, 560.35.03, Python 3.12.7
See https://gist.github.com/Thyre/27176ff279dcc36509c6a16434627367 for a full test report.

[Thyre]

Additional EasyConfigs tested with latest changes:

• {devel,tools,lib,compiler}[system/system,GCCcore/14.2.0] Add pkgconf 2.3.0, XZ 5.6.3, ncurses 6.5, libxml 2.13.4, AOCC 5.0.0 easybuild-easyconfigs#21629
• {compiler}[GCCcore/13.3.0] AOCC v4.2.0 easybuild-easyconfigs#21343

[SebastianAchilles]

@boegelbot please test @ jsc-zen3
EB_ARGS="AOCC-3.2.0-GCCcore-11.3.0.eb AOCC-4.0.0-GCCcore-12.3.0.eb"

[boegelbot]

@SebastianAchilles: 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=3480 EB_ARGS="AOCC-3.2.0-GCCcore-11.3.0.eb AOCC-4.0.0-GCCcore-12.3.0.eb" EB_REPO=easybuild-easyblocks EB_BRANCH=develop /opt/software/slurm/bin/sbatch --job-name test_PR_3480 --ntasks=8 ~/boegelbot/eb_from_pr_upload_jsc-zen3.sh' executed!

• exit code: 0
• output:

Submitted batch job 5071

Test results coming soon (I hope)...

- notification for comment with ID 2411244077 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 AOCC-3.2.0-GCCcore-11.3.0.eb
• SUCCESS AOCC-4.0.0-GCCcore-12.3.0.eb

Build succeeded for 2 out of 2 (2 easyconfigs in total)
jsczen3c1.int.jsc-zen3.fz-juelich.de - Linux Rocky Linux 9.4, x86_64, AMD EPYC-Milan Processor (zen3), Python 3.9.18
See https://gist.github.com/boegelbot/17e753953e6d2a19c348c13ec30d56d5 for a full test report.

[SebastianAchilles]

@boegelbot please test @ jsc-zen3
EB_ARGS="AOCC-3.2.0-GCCcore-11.3.0.eb AOCC-4.0.0-GCCcore-12.3.0.eb"

[boegelbot]

@SebastianAchilles: 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=3480 EB_ARGS="AOCC-3.2.0-GCCcore-11.3.0.eb AOCC-4.0.0-GCCcore-12.3.0.eb" EB_REPO=easybuild-easyblocks EB_BRANCH=develop /opt/software/slurm/bin/sbatch --job-name test_PR_3480 --ntasks=8 ~/boegelbot/eb_from_pr_upload_jsc-zen3.sh' executed!

• exit code: 0
• output:

Submitted batch job 5074

Test results coming soon (I hope)...

- notification for comment with ID 2413144605 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 AOCC-3.2.0-GCCcore-11.3.0.eb
• SUCCESS AOCC-4.0.0-GCCcore-12.3.0.eb

Build succeeded for 2 out of 2 (2 easyconfigs in total)
jsczen3c1.int.jsc-zen3.fz-juelich.de - Linux Rocky Linux 9.4, x86_64, AMD EPYC-Milan Processor (zen3), Python 3.9.18
See https://gist.github.com/boegelbot/53f19feaee328b967d001b1f44065dc8 for a full test report.

[Thyre]

The PR should be ready from my side. I only moved the wrapper script definition back to its initial place to stay consistent.

[SebastianAchilles]

@Thyre Fine by me, whatever you prefer. Maybe if this are functions meant/needed to be used across multiple easyblocks i could try to generalize them so they can just be imported and used with the appropriate version checks

@Crivella I think it would be a good idea, as similar sanity checks might be useful for other LLVM-based compilers (like AOCC, AOMP, oneAPI).

I think this is a good idea as well. I would suggest that we merge this PR as is to be able to use the newer AOCC. If we want to generalize the features, we could do that in a follow-up PR.

[SebastianAchilles]

lgtm

[SebastianAchilles]

Going in, thanks @Thyre!