Summary

Similar to the 2022.1 stack before it, the 2022.2 stack uses an intermediate layer to build against in order to make it independent of the underlying OS. However, unlike the 2022.1 stack that used a cross compile environment with a full suite of utilities and tools, the 2022.2 stack uses only the cross compile toolchain. This should reduce the overhead and actually integrate better with the underlying OS.

Notes

If a package is missing from this stack that was present in previous stacks it is most likely due to build problems with new versions, either the package itself or its dependencies, or having new requirements. These will take longer to get working and were left out in order to not hold up the bulk of the stack. They will either be added as incremental updates to this stack or be part of the next stack.

Crosstool-NG toolchain

The 2022.2 stack is built against a Crosstool-NG toolchain, providing the GCC compiler, linker, and related tools for compiling. These will be loaded into the PATH when the stack/2022.2 module is loaded. For the most part, this should be transparent but is something to be aware of when using the stack for development.

Problematic Environment Variables

There are some environment variables that are problematic when loaded with environment modules as they can conflict with each other as well as system software. These variables are generally used for development. They are:

• C_INCLUDE_PATH 

• CPLUS_INCLUDE_PATH 

• INCLUDE 

• LIBRARY_PATH 

• LD_LIBRARY_PATH 

Technically, LD_LIBRARY_PATH is a run-time variable and not used for development, but it is also the one that causes the most problems. All of these variables have been left unset for the 2022.2 stack by default. If these are needed for development, or LD_LIBRARY_PATH is needed at run-time for user compiled software, there is a way to activate them. See below for details.

Usage

This stack should behave like other stacks and feel "less different" than the 2022.1 stack due to only replacing the toolchain. Using the 2022.2 stack with environment modules is just like any other stack on Argon. There are a few things to be aware of when using the software packages for development, however. As noted above, several development related variables are not set. The CMAKE_PREFIX_PATH and PKG_CONFIG_PATH variables are set and those should be sufficient for software that uses cmake and pkgconfig. In addition, every package has a ROOT_PACKAGE variable, where PACKAGE is the actual name of the package, pointing to the root of the installation. For instance, ROOT_ZLIB will point to the root of the zlib installation, so library and header paths could be set with $ROOT_ZLIB/lib and $ROOT_ZLIB/include, respectively, in your Makefile. However , there may be situations where the unset development variables may be useful. For those cases, there are corresponding -dev modules that can be loaded to replace the respective default module. For instance, if zlib/1.2.13_gcc-9.5.0-dev is loaded, it will replace zlib/1.2.13_gcc-9.5.0 and set the appropriate values for the *INCLUDE_PATH and *LIBRARY_PATH variables for zlib. You may also need to have one or more -dev modules loaded at run-time if your compiled package was not built with RPATH support. 

Compilers

GCC

The GCC-9.5.0 compiler is loaded when the 2022.2 stack is loaded. This is what the software stack is built from and is generally the best option.

Intel

The Intel compilers, classic and OneAPI, are set up to use the GCC and SYSROOT of the toolchain. Note that Intel has deprecated the classic "intel" compiler and will be switching to the LLVM based OneAPI compiler. The 2022.2 stack builds a few key applications with the classic intel compiler and OneAPI built applications will probably land in the next stack.

NVHPC

The NVHPC compiler is installed per request. It is not used to build anything in the stack and has not been integrated to use the toolchain and SYSROOT, so you may have to take extra steps if wishing to use this compiler.

Software List