easybuilders
In several of the compiler toolchains, some of the toolchainopts seem to have no effect.
Consider, e.g., the following easyconfig file:
easyblock = 'MakeCp'
name = 'Hello-World'
version = '0.1'
homepage = 'https://github.com/klust/Hello-World'
whatis = [
'Description: Mostly a simple EasyBuild test of the compiler toolchains',
]
description = """
This is a test for the compiler toolchains.
"""
toolchain = {'name': 'GCC', 'version': '9.3.0'}
toolchainopts = {'unroll': True, 'loop': True, 'lto': True}
# https://github.com/klust/Hello-World/archive/refs/tags/v0.1.tar.gz
source_urls = ['https://github.com/klust/Hello-World/archive/refs/tags']
sources = ['v%(version)s.tar.gz']
files_to_copy = [(['hello'], 'bin')]
sanity_check_paths = {
'files': ['bin/hello'],
'dirs': [],
}
moduleclass = 'tools'
I use the GCC toolchain to demonstrate the problem but it is present in several of the toolchains. I bumped into it when I checked the Cray toolchains for LUMI.
When running this EasyConfig with the -x option (or even just running it, the repository should be a valid one), you'll note that the 'unroll' flag does indeed add -funroll-loops to the compiler flags as expected, but 'loop' doesn't add the four options that it should add, or 'lto' doesn't add -flto.
This happens with compiler-specific options defined through COMPILER_UNIQUE_OPTS. It is not enough to declare those options in COMPILER_UNIQUE_OPTS and then define the compiler flags in COMPILER_UNIQUE_OPTION_MAP. EasyBuild must also know for which compiler they apply (C/C++ and/or Fortran). There is no COMPILER_UNIQUE_FLAGS equivalent to COMPILER_FLAGS in the generic tools/tooclchain.compiler.py file, so the options defined through COMPILER_UNIQUE_OPTS should be added to COMPILER_C_UNIQUE_FLAGS and/or COMPILER_F_UNIQUE_FLAGS, depending on the languages to which they apply.
This is in fact clearly demonstrated in the Intel toolchain (toolchains/compiler/inteliccifort.py file): Switching to the Intel toolchain in the above easyconfig file with
toolchain = {'name': 'intel', 'version': '2020a'}
toolchainopts = {'intel-static': True, 'no-icc': True, 'error-unknown-option': True}
and again performing a dry run (or a regular run and checking the log file) will show that the options 'intel-static' and 'no-icc' do indeed add compiler flags to CFLAGS but 'error-unknown-option' does not, and checking the compiler definition reveals that 'intel-static' and 'no-icc' are indeed added to COMPILER_C_UNIQUE_FLAGS and/or COMPILER_F_UNIQUE_FLAGS, but 'error-unknown-option' is not.
@klust Thanks a lot for the detailed bug report!
Since you've figured out the root of the problem, are you up for looking into contributing a fix too?
If not, just let us know...
As I don't have most of those toolchains installed on either of my local installs (Antwerp and LUMI) it is kind of hard for me to really test a fix. I did implement the suggested fixes in the Cray toolchains for LUMI though, but they have become rather different from those used at CSCS (the craype.py file) so I guess those shouldn't be contributed back without talking to CSCS to see what they think about it.
I just ran into the same issue ('lto' toolchain option ignored for a GCCcore package). Unfortunately, just adding lto to COMPILER_C_UNIQUE_FLAGS and COMPILER_F_UNIQUE_FLAGS in toolchains/compiler/gcc.py is not sufficient. At least for GCC one also needs to use the LTO-aware gcc-(ar|nm|ranlib) wrappers for LTO to work. And how to enforce those is build system (i.e., easyblock) specific... :confused:
