Test report by @Thyre
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in total)
fedora.fritz.box - Linux Fedora Linux 42, x86_64, AMD Ryzen AI 7 350 w/ Radeon 860M, 1 x AMD Krackan [Radeon 840M / 860M Graphics] (device id: 0x1114, gfx: gfx1152, driver: 6.14.3-300.fc42.x86_64), Python 3.13.3
See https://gist.github.com/Thyre/793c9866e286c956070e4c7507343f06 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 [RX 9070/9070 XT] (device id: 0x7550, gfx: gfx1201, driver: 6.14.3-arch1-1), 1 x AMD Raphael (device id: 0x164e, gfx: gfx1036, driver: 6.14.3-arch1-1), Python 3.13.3
See https://gist.github.com/Thyre/e493ec3de14d20b558652df0847d173a for a full test report.

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, 565.57.01, Python 3.10.12
See https://gist.github.com/Thyre/51fdeaf3d2e7e106100cd1ddba748dfb 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=22798 EB_ARGS= EB_CONTAINER= EB_REPO=easybuild-easyconfigs EB_BRANCH=develop /opt/software/slurm/bin/sbatch --job-name test_PR_22798 --ntasks=8 ~/boegelbot/eb_from_pr_upload_jsc-zen3.sh' executed!

• exit code: 0
• output:

Submitted batch job 6222

Test results coming soon (I hope)...

Test report by @boegelbot
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in total)
jsczen3c2.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/b9064a61b1b52ef2dc070097441648d1 for a full test report.

Test report by @jfgrimm
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in total)
node117.viking2.yor.alces.network - Linux Rocky Linux 8.9, x86_64, AMD EPYC 7643 48-Core Processor, Python 3.6.8
See https://gist.github.com/jfgrimm/1d5da1c04c2a713801f6c0903d196871 for a full test report.

Going in, thanks @Thyre!

Just taking a note here: while testing easybuilders/easybuild-easyblocks#3728, I noticed that this causes trouble to build M4/1.4.19 on old OS versions like CentOS 7.

Building fails with:

explicit_bzero.c: In function 'explicit_bzero':
explicit_bzero.c:60:3: error: 'asm' undeclared (first use in this function)
   asm volatile ("" ::: "memory");
   ^
explicit_bzero.c:60:3: note: each undeclared identifier is reported only once for each function it appears in
explicit_bzero.c:60:7: error: expected ';' before 'volatile'
   asm volatile ("" ::: "memory");
       ^
make[4]: *** [explicit_bzero.o] Error 1

Not using -std=c99 in $CFLAGS fixes that.

I won't spend more time on this since I consider CentOS 7 to unsupported (since it's EOL since June 2024), but may be useful info in case someone hits this problem...

Just taking a note here: while testing easybuilders/easybuild-easyblocks#3728, I noticed that this causes trouble to build M4/1.4.19 on old OS versions like CentOS 7.
[...]
Not using -std=c99 in $CFLAGS fixes that.

The GCC version used by CentOS 7 disables certain extensions, including asm, once one passes any -std standard. This is documented, e.g. for GCC 4.1: https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Alternate-Keywords.html
Theoretically, this should still happen with GCC 15.1.0 (according to the documentation), but does not?

The keywords asm, typeof and inline are not available in programs compiled with -ansi or -std (although inline can be used in a program compiled with -std=c99)

The failing code wrongly assumes that the asm keyword is always available when building with GCC. This causes the build failure of the test explicit_bzero.c:

#elif defined __GNUC__ && !defined __clang__
  memset (s, '\0', len);
  /* Compiler barrier.  */
  asm volatile ("" ::: "memory");
#elif defined __clang__
  memset (s, '\0', len);
  /* Compiler barrier.  */
  /* With asm ("" ::: "memory") LLVM analyzes uses of 's' and finds that the
     whole thing is dead and eliminates it.  Use 'g' to work around this
     problem.  See <https://bugs.llvm.org/show_bug.cgi?id=15495#c11>.  */
  __asm__ volatile ("" : : "g"(s) : "memory");

The solution is described in the same GCC documentation:

The way to solve these problems is to put __ at the beginning and end of each problematical keyword. For example, use __asm__ instead of asm, and __inline__ instead of inline.

Theoretically, this should be checked by the M4 configure, but is not...
I see a few options here:

• Revert the changed flag. This breaks building older toolchains relying on a system M4 1.4.19 with GCC 15, but people can try 1.4.20 which solves this issue.
• Create a patch for M4 1.4.19 which updates just this single test to use __asm__. This was enough to build in a CentOS 7 container, though I have not checked the full install process.
• Do nothing, as this affects, as far as we know so far, only older distributions.

I tend towards one of the first two options. People using GCC 15 will also likely run into issues because of having binutils 2.44 on the system, which also requires some manual work to get older toolchains running anyway (filtering binutils deps or use 2.44 instead of 2.4x for the toolchain).

Opened #22998 to address the issue. I chose a patch, since this reduces the work a user might need to do to install older toolchains.