After attempting to install Quantum Espresso with easybuild, I've noticed that (for sure for the intel toolchain, also have to test in depth for the foss one) that many of the libraries supposedly being used are not actually linked to the executables.
This has also been reported by other users on slack
As an example this is the result of ldd on the 7.2-intel-2022b version
linux-vdso.so.1 (0x00007ffd9f1b8000)
libiomp5.so => ~/.local/easybuild/software/imkl/2022.2.1/compiler/2022.2.1/linux/compiler/lib/intel64_lin/libiomp5.so (0x00007f3d3d600000)
libsz.so.2 => ~/.local/easybuild/software/Szip/2.1.1-GCCcore-12.2.0/lib/libsz.so.2 (0x00007f3d3db23000)
libz.so.1 => ~/.local/easybuild/software/zlib/1.2.12-GCCcore-12.2.0/lib/libz.so.1 (0x00007f3d3db08000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3d3d519000)
libxcf90.so.12 => ~/.local/easybuild/software/libxc/6.1.0-intel-compilers-2022.2.1/lib/libxcf90.so.12 (0x00007f3d3daec000)
libxcf03.so.12 => ~/.local/easybuild/software/libxc/6.1.0-intel-compilers-2022.2.1/lib/libxcf03.so.12 (0x00007f3d3dae3000)
libxc.so.12 => ~/.local/easybuild/software/libxc/6.1.0-intel-compilers-2022.2.1/lib/libxc.so.12 (0x00007f3d35200000)
libmpifort.so.12 => ~/.local/easybuild/software/impi/2021.7.1-intel-compilers-2022.2.1/mpi/2021.7.1/lib/libmpifort.so.12 (0x00007f3d34e00000)
libmpi.so.12 => ~/.local/easybuild/software/impi/2021.7.1-intel-compilers-2022.2.1/mpi/2021.7.1/lib/release/libmpi.so.12 (0x00007f3d33400000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3d33000000)
libgcc_s.so.1 => ~/.local/easybuild/software/GCCcore/12.2.0/lib64/libgcc_s.so.1 (0x00007f3d3dac0000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f3d3dabb000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3d3dab4000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3d3db40000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3d3daaf000)
libifport.so.5 => ~/.local/easybuild/software/intel-compilers/2022.2.1/compiler/2022.2.1/linux/compiler/lib/intel64_lin/libifport.so.5 (0x00007f3d3da86000)
libifcoremt.so.5 => ~/.local/easybuild/software/intel-compilers/2022.2.1/compiler/2022.2.1/linux/compiler/lib/intel64_lin/libifcoremt.so.5 (0x00007f3d3d3aa000)
libimf.so => ~/.local/easybuild/software/imkl/2022.2.1/compiler/2022.2.1/linux/compiler/lib/intel64_lin/libimf.so (0x00007f3d32c00000)
libsvml.so => ~/.local/easybuild/software/imkl/2022.2.1/compiler/2022.2.1/linux/compiler/lib/intel64_lin/libsvml.so (0x00007f3d31400000)
libintlc.so.5 => ~/.local/easybuild/software/imkl/2022.2.1/compiler/2022.2.1/linux/compiler/lib/intel64_lin/libintlc.so.5 (0x00007f3d34d8e000)
libirng.so => ~/.local/easybuild/software/imkl/2022.2.1/compiler/2022.2.1/linux/compiler/lib/intel64_lin/libirng.so (0x00007f3d31000000)
Scalapack libraries are not actually being linked, and ELPA (linked statically) are not actually causing an issue there because also the flag enabling them is being improperly set
I have been having a look at the Quantum ESPRESSO easyblock file and the issues stems from there, as the flag being overwritten after the ./configure step are being replaced with older version, not kept in sync with this definitions from the QE repo
I started working on an updated version.
One thing that would be useful to know is for how far back do we want to keep the compatibility for Quantum Espresso.
E.G.: Starting from 6.x and definitely from 7.x, the ./configure script has been much improved and in most cases it would probably be easier to just use configure flags without manually overriding the make.[inc/sys] file.
Starting from version 6.7 also a CMake implementation has been added
The way it is being done right now is a lot of nested if checks, which might become cumbersome to maintain without implementing some sort of compatibility matrix and actions
After attempting to install Quantum Espresso with easybuild, I've noticed that (for sure for the intel toolchain, also have to test in depth for the foss one) that many of the libraries supposedly being used are not actually linked to the executables.
This has also been reported by other users on slack
As an example this is the result of
lddon the7.2-intel-2022bversionScalapack libraries are not actually being linked, and ELPA (linked statically) are not actually causing an issue there because also the flag enabling them is being improperly set
I have been having a look at the Quantum ESPRESSO easyblock file and the issues stems from there, as the flag being overwritten after the
./configurestep are being replaced with older version, not kept in sync with this definitions from the QE repoI started working on an updated version.
One thing that would be useful to know is for how far back do we want to keep the compatibility for Quantum Espresso.
E.G.: Starting from 6.x and definitely from 7.x, the
./configurescript has been much improved and in most cases it would probably be easier to just use configure flags without manually overriding themake.[inc/sys]file.Starting from version 6.7 also a CMake implementation has been added
The way it is being done right now is a lot of nested
ifchecks, which might become cumbersome to maintain without implementing some sort of compatibility matrix and actions