compilation of `xtb` 6.7.1 failing

[boegel]

Describe the bug

compilation of xtb 6.7.1 is failing with GCC 12.3.0 is failing with:

[526/899] Compiling Fortran object libxtb.so.6.7.1.p/src_dipro_xtb.F90.o
FAILED: libxtb.so.6.7.1.p/src_dipro_xtb.F90.o libxtb.so.6.7.1.p/xtb_dipro_xtb.mod
gfortran -Ilibxtb.so.6.7.1.p -I. -I../xtb-6.7.1 -I../xtb-6.7.1/include -Isubprojects/mctc-lib/libmctc-lib.a.p -Isubprojects/json-fortran-8.2.5/libjsonfortran.a.p -I../xtb-6.7.1/subprojects/tblite/include -Isubprojects/tblite/libtblite.a.p -Isubprojects/dftd4/libdftd4.a.p -I../xtb-6.7.1/subprojects/dftd4/include -Isubprojects/multicharge/libmulticharge.a.p -Isubprojects/s-dftd3/libs-dftd3.a.p -I../xtb-6.7.1/subprojects/s-dftd3/include -Isubprojects/toml-f/libtoml-f.a.p -Isubprojects/numsa/libnumsa.a.p -Isubprojects/cpx/libcpx.a.p -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -O2 -fdefault-real-8 -fdefault-double-8 -ffree-line-length-none -fbacktrace -O2 -ftree-vectorize -march=native -fno-math-errno -fPIC -fopenmp -pthread -fopenmp -DWITH_TBLITE=1 -DWITH_CPCMX=1 -Jlibxtb.so.6.7.1.p -o libxtb.so.6.7.1.p/src_dipro_xtb.F90.o -c ../xtb-6.7.1/src/dipro/xtb.F90
../xtb-6.7.1/src/dipro/xtb.F90:53:42:

   53 |       call new_gfn2_calculator(xcalc, mol)
      |                                          1
Error: Missing actual argument for argument error at (1)
../xtb-6.7.1/src/dipro/xtb.F90:55:42:

   55 |       call new_gfn1_calculator(xcalc, mol)
      |                                          1
Error: Missing actual argument for argument error at (1)
../xtb-6.7.1/src/dipro/xtb.F90:57:43:

   57 |       call new_ipea1_calculator(xcalc, mol)
      |                                           1
Error: Missing actual argument for argument error at (1)

To Reproduce

export FFLAGS="-O2 -ftree-vectorize -march=native -fno-math-errno"
meson setup --prefix /tmp/xtb-6.7.1 -Dlapack='custom' -Dcustom_libraries='flexiblas' --buildtype release  -Dlibdir=lib  /tmp/xtb-6.7.1
ninja -j 8

Expected behaviour

Compilation works (as it did before).

Additional context

Same problem with xtb 6.7.0, which we know worked fine before, it start of failing all of a sudden, probably because xtb downloads the latest version of tblite and due to https://github.com/tblite/tblite/pull/188, see also https://github.com/easybuilders/easybuild-easyconfigs/issues/21243.

Can we somehow prevent that xtb downloads whatever the latest version of tblite (or others) is, which makes the build essentially not reproducible?

[boegel]

It seems like #1072 probably fixes this, but that doesn't change that anyone trying to build xtb 6.7.1 will be hitting this problem...

How can we prevent similar situations going forward?

[marcelmbn]

The error is somewhat expected because xtb fetches always the latest commit of tblite (as defined here: https://github.com/grimme-lab/xtb/blob/main/subprojects/tblite.wrap). A solution for the future would be either i) more regular tblite releases so that we could always point to a fixed release, or ii) we try to point to a specific commit (but not sure if that's possible. The fact that tblite updates break the API probably can't be ruled out in the future. Btw, the statically linked release binaries are not affected in general.

Another alternativ is building xtb-light (see CI and Docs for instructions) which does not include the tblite dependency (depending on your needs).

[boegel]

@marcelmbn Thanks for the reply.

I also noticed that the latest head of tblite is automatically pulled in, which of course inevitably leads to a broken build at some point.

That's also my main motivation for reporting this particular build problem. Although it's relatively easy to fix this time (thanks to the changes in #1072), it's bound to happen again, and frankly it's a bit worrying that the from-source build of xtb is not reproducible over time.

I hope that xtb can at least go forward with downloading specific versions/commits of dependencies like tblite, so builds are reproducible going forward.

What would be even better is if there's a (documented) way of "seeding in" specific versions of these dependencies, so that they're not being downloaded on the fly during the build (which makes offline building impossible).

Is the latter already possible somehow, can the downloading of dependencies be avoided somehow?

[marcelmbn]

What would be even better is if there's a (documented) way of "seeding in" specific versions of these dependencies, so that they're not being downloaded on the fly during the build (which makes offline building impossible).

Is the latter already possible somehow, can the downloading of dependencies be avoided somehow?

The dependencies are downloaded during the setup of the build meson setup ... because meson expects them to be there but does not find them. Not sure if that is exactly what you mean, but it can of course be simply circumvented by setting up the build at one given point of time then make changes to the code and meson compile whenever necessary. Then, dependencies won't be downloaded again, but only if you delete them by rm -rf subprojects or similar.

[marcelmbn]

@marcelmbn Thanks for the reply.

I also noticed that the latest head of tblite is automatically pulled in, which of course inevitably leads to a broken build at some point.

That's also my main motivation for reporting this particular build problem. Although it's relatively easy to fix this time (thanks to the changes in #1072), it's bound to happen again, and frankly it's a bit worrying that the from-source build of xtb is not reproducible over time.

I hope that xtb can at least go forward with downloading specific versions/commits of dependencies like tblite, so builds are reproducible going forward.

Definitely agree with that! I will leave the issue open and ASAP introduce a specific commit/tag/release into the tblite dependency so that we always pull the same code and only update it with more recent xtb versions.

[marcelmbn]

Maybe also something to have in mind for you, @Albkat