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.

...

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.

...

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. 

...