EasyBuild¶

Starting with HoreKa 2 toolchains and scientific software are provided using EasyBuild. EasyBuild is a well established and consistent way to provide scientific software at many HPC sites all over the world. Since the naming of EasyBuild modules is consistent users can use modules with the same name at different sites. To make this possible, EasyBuild software minimizes the resources used by the local operating system and provides most software independently. This makes scientific results more reproducible.

Using EasyBuild modules¶

Horeka 2 users have access to a complete EasyBuild module tree, providing compiler toolchains, libraries, and scientific software. The Lmod module command is used to access the EasyBuild modules.

EasyBuild conventions¶

The EasyBuild team has decided to provide one or two toolchain versions a year for the most common compiler suits. Each toolchain defines one version of compiler, MPI library, math libraries and other packages as default for all software built aginst this toolchain. For a complete list of EasyBuild toolchains, please see the EasyBuild website. Currently a variety of tool chains and versions is available on HoreKa 2. The 2025b and 2026.1 versions are the most recent ones. Some software may not be available for the latest toolchain yet, but may be available for an older toolchain.

EasyBuild currently supports about 4000 software packages. Horeka 2 can and will only provide a subset. With the start of HoreKA 2 we will offer current versions of popular software packages from HoreKa. Additional packages are provided over time on request. If we can't provide the software you can still use the advantages of EasyBuild by using it to build your private version.

Build individual EasyBuild packages as a user¶

EasyBuild can also be used to compile your own or niche software. The HoreKa 2 EasyBuild tree can be used as a base to build additional software in your home or a workspace directory.

For this example we assume the following:

• The sofware will be installed in your HOME directory in the sub-directory eb
• You have already cloned the easyconfigs github repository to ~/eb/easybuild-easyconfigs

EasyBuild configuration file¶

The configuration file must be placed in your home at ~/.config/easybuild/config.cfg with the following content:

[basic]
robot=<path_to_your_home>/eb/easybuild-easyconfigs/easybuild/easyconfigs
[config]
modules-tool: Lmod
prefix=<path_to_your_home>/eb
buildpath=/scratch/build
[override]
allow-modules-tool-mismatch=True

• robot: tell EasyBuild where to look for EasyConfig files and build all dependencies automatically
• modules-tool: define what flavour of modules to use when creating the module files, in this case: Lua modules
• prefix: define the root path, where the software and module files are going to be installed
• buildpath: specify where to build the software, especially when the build touches a lot of files, building in /scratch is faster and will not impact the parallel file system
• group-writable-installdir: make sure the whole group has write permissions on the installed files
• cuda-compute-capabilities: specify what CUDA compute capabilities should be supported, the mapping is available here.
• amdgcn-capabilities: specify what AMD GPUs to support, the mapping is available [here],(https://rocm.docs.amd.com/en/latest/reference/gpu-arch-specs.html)
• accept-eula-for: will accept the EULAs for some software packages beforehand. This makes it possible to install these software packages without user interaction

This is only a subset of options. For more details check the documentation.

Add local/private module path¶

mkdir -p ~/eb/modules/all
module use ~/eb/modules/all
module load EasyBuild

Find or create EasyBuild file¶

look in your easybuild-easyconfigs directory for a matching EasyBuild file like

ls ~/eb/easybuild-easyconfigs/easybuild/easyconfigs/*/* | grep eb$

If there is no match, you may check for pull-requests. If there is still no match you may adapt another eb file or create a new one. More details below.

Build your software with EasyBuild¶

module load EasyBuild
eb cowsay-3.04.eb

Use your software¶

module load cowsay
cowsay "Hello EasyBuild"
_________________
< Hello EasyBuild >
-----------------
        \   ^__^
        \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

EasyBuild specifics¶

EasyBuild is a community driven software to provide a reproducible way to build software on computer systems (not limited to HPC). Most community members are from Europe and several HPC sites are actively developing and updating the software.

EasyBuild itself is implemented in Python. It uses EasyConfig files (file extension .eb) to describe the build process. In contrast to Spack which uses pure python files to describe the process.

EasyBuild tries to be as independent of the underlying operating system as possible. For this reason many low-level packages are included. With EasyBuild, loading a module will automatically load all the dependent lower level modules and the output of module list will be rather long, e.g. if you load the foss toolchain, you will see obvious dependencies like a GCC compiler and OpenMPI but also a lot of lower level modules like binutils and UCX.

module load foss/2025b
module list

Currently Loaded Modules:
  1) GCCcore/14.3.0                      13) libfabric/2.1.0-GCCcore-14.3.0
  2) zlib/1.3.1-GCCcore-14.3.0           14) PMIx/5.0.8-GCCcore-14.3.0
  3) binutils/2.44-GCCcore-14.3.0        15) PRRTE/3.0.11-GCCcore-14.3.0
  4) GCC/14.3.0                          16) UCC/1.4.4-GCCcore-14.3.0
  5) numactl/2.0.19-GCCcore-14.3.0       17) OpenMPI/5.0.8-GCC-14.3.0
  6) XZ/5.8.1-GCCcore-14.3.0             18) OpenBLAS/0.3.30-GCC-14.3.0
  7) libxml2/2.14.3-GCCcore-14.3.0       19) FlexiBLAS/3.4.5-GCC-14.3.0
  8) libpciaccess/0.18.1-GCCcore-14.3.0  20) FFTW/3.3.10-GCC-14.3.0
  9) hwloc/2.12.1-GCCcore-14.3.0         21) gompi/2025b
 10) OpenSSL/3                           22) FFTW.MPI/3.3.10-gompi-2025b
 11) libevent/2.1.12-GCCcore-14.3.0      23) ScaLAPACK/2.2.2-gompi-2025b-fb
 12) UCX/1.19.0-GCCcore-14.3.0           24) foss/2025b

Toolchain¶

A toolchain is a collection of modules which are used in common to build software. Usually each toolchain has one compiler suite, zero or one MPI implementation and one ore more other libraries, e.g. math libraries.

Toolchains can be hierarchical e.g. foss is an extension of gompi. A combination of the starting letters of these components usually is part of the rather cryptic name of such a toolchain. A complete list of available toolchains can be found here. Toolchains are defined/released once or twice a year. The toolchain versions used to be the year and a or b for the first and second release of the year. An example toolchain version string is 2025b and the matching foss toolchain is foss/2025b. There will be a change for the next toolchains. The Easybuild community is currently switching to a different naming scheme using dots and numbers. The current version string at the time of writing is 2026.1

There is a special system tool chain, which is uses the tools provided by the underlying operating system. This toolchain is required for basic modules and should not be used for scientific software modules.

HoreKa 2 has multiple toolchains in multiple versions. Not every software is compatible with each and every toolchain or compiler. The x86_64 partitions of HoreKa 2 will offer GCC and Intel compiler toolchains in multiple versions.

In contrast to HoreKa, compilers and toolchains installed on HoreKa 2 will be available for the whole life time of the system.

EasyBlock¶

EasyBlock are used to describe how the software is build on a lower level. Usually, only a few variables and dependencies are set in the EasyConfig file. The details on how parameters used in the .eb file will impact the build process are defined there. EasyBlock are used to abstract/hide the complexity of the build process.

Beside generic easyblocks like ConfigureMake, CMakeMake and Scons more complex EasyBlock for specific applications are available. Most application specific EasyBlock are extensions of a generic EasyBlock and add specific extensions. In most cases it is not necessary to write your own EasyBlock.

EasyConfig files (.eb)¶

The EasyConfig file describe the build process in plain text.

Each EasyConfig file - uses an EasyBlock, if no EasyBlock is specified, EasyBuild will look for an EasyBlock matching the name of the software (see example). - uses exactly one toolchain, since toolchains are hierarchical it's recommended to use the one with the least dependencies. - has common meta-data information like name, version. - link to the sources, local patch files, optional checksums can be specified to make sure the downloaded sources and patches are correct. These optional checksums will be verified before the build starts - a list of build and runtime dependencies - variables can be set to influence every step of the process e.g. preconfigopts = 'autoreconf && ' - steps can be skipped, e.g. skipsteps =['configure', 'check']

Example using a generic EasyBlock¶

easyblock = 'ConfigureMake'
name = 'zlib'
version = '1.3.1'
homepage = 'https://www.zlib.net/'
description = """zlib is designed to be a free, general-purpose, legally unencumbered
                -- that is, not covered by any patents -- lossless data-compression
                library for use on virtually any computer hardware and operating system."""
toolchain = {'name': 'GCCcore', 'version': '14.3.0'}
toolchainopts = {'pic': True}
source_urls = ['https://zlib.net/fossils']
sources = [SOURCELOWER_TAR_GZ]
checksums = ['9a93b2b7dfdac77ceba5a558a580e74667dd6fede4585b91eefb60f03b72df23']
# use same binutils version that was used when building GCC toolchain
builddependencies = [('binutils', '2.44', '', SYSTEM)]
sanity_check_paths = {
  'files': ['include/zconf.h', 'include/zlib.h',
            'lib/libz.a', 'lib/libz.%s' % SHLIB_EXT],
}
moduleclass = 'lib'

Example using a custom EasyBlock¶

name = 'bzip2'
version = '1.0.8'
homepage = 'https://sourceware.org/bzip2'
description = """
 bzip2 is a freely available, patent free, high-quality data compressor. It
 typically compresses files to within 10% to 15% of the best available
 techniques (the PPM family of statistical compressors), whilst being around
 twice as fast at compression and six times faster at decompression.
"""
toolchain = {'name': 'GCCcore', 'version': '14.3.0'}
toolchainopts = {'pic': True}
source_urls = ['https://sourceware.org/pub/%(name)s/']
sources = [SOURCE_TAR_GZ]
patches = ['bzip2-%(version)s-pkgconfig.patch']
checksums = [
 'ab5a03176ee106d3f0fa90e381da478ddae405918153cca248e682cd0c4a2269', # bzip2-1.0.8.tar.gz
 '9299e8ee4d014ea973777b6ea90661fe329dfa991f822add4c763ea9ddb9aab1', # bzip2-1.0.8-pkgconfig.patch
]
builddependencies = [
    ('binutils', '2.44'),
]
moduleclass = 'tools'

EasyBuild process steps¶

EasyBuild knows about the following steps: fetch, ready, extract, patch, prepare, configure, build, test, install, extensions, postiter, postproc, sanitycheck, cleanup, module, permissions, package, testcases. Every step can be influenced in the EasyConfig or EasyBlock file. In most cases this will not be necessary. Defining a sanity check is always a good idea.

Provide an updated version of software already in EasyBuild¶

The version you are looking for may be included in the git repo already. If not, check if there is a version in one of the pull requests.

Building software from pull requests¶

EasyBuild provides a convenient way to build software directly from a pull request, by specifying the pull request number, e.g.

eb --from-pr=23304

eb --from-pr=26394,25509,25657,26027,26028,26025,26108 --ignore-test-failure

eb b/BLIS/BLIS-2.0-GCC-15.2.0.eb --include-easyblocks-from-pr=4034

Updating EasyConfigs manually¶

If an EasyBuild file for a new version is not available yet, start with updating an older .eb file and update version, toolchain and dependencies. Finding the correct versions of all the dependencies can be a lengthy process. EasyBuild provides a number of options, that may help with updating:

--try-software=NAME,VERSION
Try to search and build software with given name and version (USE WITH CARE!) (type comma-separated list)
--try-software-name=NAME
Try to search and build software with given name (USE WITH CARE!)
--try-software-version=VERSION
Try to search and build software with given version (USE WITH CARE!)
--try-toolchain=NAME,VERSION
Try to search and build with given toolchain (name and version) (USE WITH CARE!) (type comma-separated list)
--try-toolchain-name=NAME
Try to search and build with given toolchain name (USE WITH CARE!)
--try-toolchain-version=VERSION
Try to search and build with given toolchain version (USE WITH CARE!)
--try-update-deps   Try to update versions of the dependencies of an easyconfig based on what is available in the robot path (default: False)

If you are building the latest version for the latest toolchain you may need to create EasyConfig files for most/some/all dependencies as well, since they may not be available for the latest toolchain version yet.

If modules with many sub-packages/modules are involved (e.g. Python, Rust or R bundle), this can be rather a lot of work.

Make sure to update the checksums using eb --inject-checksums.

Finally, run eb with the new EasyConfig and fix any problem.

Create an EasyConfig file from scratch¶

1. check what build software the software to be installed is using.
2. check if there is a matching generic EasyBlock, e.g. ConfigureMake for autotools.
3. Look for an existing EasyConfig file using the same EasyBlock and use this as a starting point for your file.
4. Replace name, version, toolchain, homepage, description, sources, (build)dependencies and module class.
5. Build the software with eb and
6. fix any problems iteratively.

Install software with GPU support¶

GPU support has been integrated with EasyBuild for a long time. For CUDA based software it usually enough to add CUDA as a dependency. If the amdgcn-capabilities and/or cuda-compute-capabilities variable are set the EasyBlock should do the correct thing. The amdgcn integration still needs some manual work, like setting (compiler)options. The amdgcn and cuda-compute capabilities should be set in your EasyBuild config file see example above For tests, both options can also be passed as command line arguments, e.g.

eb --cuda-compute-capabilities=10.0 CUDA_Blackwell_software.eb

Some software packages will only build with one cuda-compute-capability. If that's the case, you need to specify the matching command line option.

Please be aware, that some software needs a GPU in the system to compile (or run tests) during the build process. Compiling on the login node will not work for all packages but you can run a interactive build session on one of the GPU development nodes.

Known problems¶

Test steps may hang or take a long time¶

Some software packages have extended test suites, which take a long time and may even hang. For these packages, it is necessary to skip the test step. Fortunately easybuild provides a command line option to do exactly that: --skip-test-step

Some packages are known to have tests, that do fail some times, in this case EasyBuild offers the option to just ignore the failed tests using the --ignore-test-failure command line option. The test step will be run but any failures are ignored and the build finishes successfully, even if the test fails.

Patching software¶

If a build, especially for a new toolchain fails, it's sometimes necessary to provide a patch. EasyBuild uses standard patches (e.g. generated with diff -uNr) for the original sources. The software admin needs to add them to the EasyConfig file in the patches section. e.g.

patches = [
    ('OpenMPI-5.0.7_build-with-internal-cuda-header.patch', 1),
    'OpenMPI-5.0.7_fix_gpfs_compatibility.patch',
]

Sources are not publicly available.¶

Some software packages (e.g. commercial software) are not provided as an online download. The sources need to be made available for EasyBuild to access. Find the source elsewhere and put it into the current directory or the matching /software/easybuild/source directory. EasyBuild will complain when it can't find the sources and will print the directories, where it's looking for the sources.

Software is not/no longer compatible with the compiler in the target toolchain.¶

Some versions of a software require an older or newer compiler than is available in your preferred toolchain. CDO being one example of a software package, which relies on current features of the C++ compilers and the latest versions will only build against a compiler providing features from a recent C++ standard. Intel compilers are known to only include subsets of new C++ standards and may fail. Make sure to check the required compiler for the software.

Intel compiler won't compile on AMD¶

At compile time the Intel compiler will check the local processor to find the best optimization. If it encounters an AMD processor it will print something like:

Please verify that both the operating system and the processor support Intel(R) X87,
CMOV, MMX, SSE, SSE2, SSE3, SSSE3, SSE4_1, SSE4_2, MOVBE,   POPCNT, AVX, F16C, FMA,
BMI, LZCNT, AVX2, AVX512F, AVX512DQ, ADX, AVX512CD,   AVX512BW, AVX512VL, AVX512VBMI,
AVX512_VPOPCNTDQ, AVX512_BITALG, AVX512_VBMI2, AVX512_VNNI and SHSTK instructions.

eb HDF5-1.14.5-iimpi-2024a.eb --optarch=-march=skylake-avx512

Advanced topics¶

Use slurm to build software¶

EasyBuild comes with a --job option, where EasyBuild will use a job scheduler like slurm to submit one or more jobs to a HPC system. The jobs will compile and install the software in the EasyBuild tree. Each dependency, which is not already installed on the system will be build in a separate job utilizing multiple nodes of a cluster. This is a convenient way to build many software packages in parallel.

If the software needs a GPU to build, the job to build it must be submitted to a GPU node. To use slurm, with EasyBuild, at least two variables need to be set: 1. to use slurm as a job backend and 2. what partition to use. On HoreKa 2 this may look like:

export EASYBUILD_JOB_BACKEND='Slurm'
export SBATCH_PARTITION='gpu-h100'

eb VTK-9.5.2-foss-2025b.eb --job --job-cores 10 --job-max-walltime 8 --trace

More details regarding jobs can be found in the EasyBuild job documentation or in the EESSI workshop material.

Build a complete software tree¶

EasyBuild provides the concept of EasyStack. An EasyStack describes a collection of software packages. These EasyStacks can be installed with one command. After calculating the dependencies, EasyBuild will build all the software specified in the EasyStack in the correct order. Naturally, this will take a long time. If one of the software packages fails to build, only the remaining packages, which do not depend on the broken one will be built.

EasyStack files are yaml files, where all the EasyConfig files are listed. Each entry can be customized to add local options or optimizations, see easystack files documentation for details.

easyconfigs:
  - ANTLR-2.7.7-GCCcore-13.3.0.eb
  - ATK-2.38.0-GCCcore-13.2.0.eb
  - Autoconf-2.71-GCCcore-13.2.0.eb
  - Autoconf-2.72-GCCcore-13.3.0.eb
  ...
  - openfoam-v2206-foss-2022a.eb:
    options:
      parallel: "1"
...

To build an EasyStack use the --easystack option like this:

eb --easystack hk2-easystack.yaml

EasyStacks can be used to describe a complete software tree for a cluster. EasyStack can also be combined with a batch system. This makes the rebuild of a complete software tree convenient and fast Of course, not all of the software will build on the first try. Re-running eb --easystack .. will only build the remaining software packages.

Further Information¶

Good EasyBuild tutorials are available at:

• Official EasyBuild tutorial
• Lumi tutorials