{lib}[system] XALT v2.8.4

[samcmill]

Adds EasyConfigs for XALT.

A few items of note:

• XALT requires a site specific configuration file at build time (--with-config). In the EasyConfig I have documented that the user should use --try-amend=config_py=<file> to specify this file. If this option is not used, then an error message with this information is printed.
• XALT has a slightly different interpretation of the install prefix than most packages. It expects the prefix to the base install directory (e.g., /opt/easybuild/software) and it appends the package name and version itself (e.g., xalt/2.7.27). The corresponding EasyBlock handles this.
• The GPU enabled variant installs in the same directory as the non-GPU variant. This is because versionsuffix does not work due to the second item.

Depends on easybuilders/easybuild-easyblocks#1942.

cc @rtmclay

[boegel]

@samcmill Installation with the latest update of the XALT easyblock in easybuilders/easybuild-easyblocks#1942 works, but it doesn't produce a working XALT installation...

I was running some commands after loading the XALT module, and noticed that nothing was being logged by XALT. When trying to figure it out, I ran into this:

$ xalt_configuration_report
/software/XALT/2.8.1/bin/../libexec/xalt_configuration_report.x: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /software/XALT/2.8.1/bin/../libexec/xalt_configuration_report.x)
/software/XALT/2.8.1/bin/../libexec/xalt_configuration_report.x: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /software/XALT/2.8.1/bin/../libexec/xalt_configuration_report.x)

The issue here is that GCCcore/7.3.0, which provides a newer libstdc++.so.6 than the OS does, was loaded at the time that XALT was being built, because it got loaded via the build dependencies (cURL, etc.).
Since GCCcore/7.3.0 isn't loaded by the XALT module, we end up with a broken installation.

We really don't want the XALT module to load a specific GCCcore though, since that would severely limit the compatibility of XALT with modules built with an older/newer toolchain.

So, I think we should:

• run xalt_configuration_report as a sanity check command in the XALT easyblock, to catch broken installations like this;
• either:
  • use dependencies built with the system toolchain (but that leaves us at the mercy of the system compiler, which may be problematic on some system);
  • if possible, make sure that libstdc++ is statically linked in XALT (maybe this is something for @rtmclay to help out with?)

[rtmclay]

Installing XALT with anything but the system gcc is a mistake. What happens when you build things with a new gcc than what is on the system and then run things with just xalt?

[samcmill]

Since toolchain = SYSTEM does not behave as expected, I think there are 3 options.

1. Modify XALT to statically link libstdc++, etc. The counter-argument is that XALT should just be built with the system gcc, period. Static linking is just masking the larger problem.

2. Replace the build dependencies with OS dependencies. The downside is that this would break for regular users if those dependencies are not installed. Some of the dependencies are not commonly installed.

3. Replace the GCC-7.3.0 build dependencies with system compiler versions. This would mean creating new easyconfigs in some cases.

4. Replace the GCC-7.3.0 build dependencies with older versioned toolchain versions. This would mean creating new easyconfigs in some cases. The other downside is that it would still mean XALT is built with something other than the system compiler.

If 1 is not viable, then 3 seems like the best choice. If there is agreement, then I will add those additional easyconfigs to this PR.

[boegel]

Installing XALT with anything but the system gcc is a mistake. What happens when you build things with a new gcc than what is on the system and then run things with just xalt?

@rtmclay That likely works as expected, but let me flip it around: what if XALT is built with a system compiler that is newer than what software was built with?

Fedora 32 ships with GCC 10.1 as system compiler. If XALT is built with the system compiler, and then software is built with GCC 8.3 (foss/2019b) or GCC 9.3 (foss/2020a), then XALT may still be broken due to incompatibilities between libstdc++.so?

libc.so is a different story, EasyBuild doesn't build it's own libc, it always uses the one from the system.

So, option 1 still seems the best way forward to me. Option 3 would work, but only if the system compiler is older than what software is being built with.

[samcmill]

The XALT EasyBlock has been updated to add the static_cxx option. If set to True, then XALT will be statically linked with libstdc++ and libgcc_s.

[boegel]

Test report by @boegel
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in this PR)
node2413.golett.os - Linux centos linux 7.7.1908, x86_64, Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz (haswell), Python 2.7.5
See https://gist.github.com/8c608f6ac2d3f0e7da991450dd324fee for a full test report.

[boegel]

Test report by @boegel
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in this PR)
node3402.kirlia.os - Linux centos linux 7.7.1908, x86_64, Intel(R) Xeon(R) Gold 6240 CPU @ 2.60GHz (cascadelake), Python 2.7.5
See https://gist.github.com/c0e168a38e34a4354529fc0e06cad508 for a full test report.

[boegel]

Going in, thanks @samcmill!