GFN0 parameters not installed by meson

[susilehtola]

Trying to run xtb in Fedora leads to the crash

########################################################################
[ERROR] Program stopped due to fatal error
-3- Could not setup parameterisation
-2- main_setup_newCalculator: Could not construct new calculator
-1- main_setup_newXTBCalculator: Parameter file param_gfn0-xtb.txt not found!
########################################################################

If the file is required at runtime, it should get installed by meson.

The GFN1, GFN2, and IPEA parameters are also not installed; however, GFN1 and GFN2 appear to run without problems also without the parameter data files...

[awvwgk]

Parameter files are usually installed in $PREFIX/share/xtb, you could add a script to /etc/profile.d to automatically include $PREFIX/share/xtb in the environment variable XTBPATH, which would allow xtb to find the parameter files for IPEA-xTB and GFN0-xTB.

Note that GFN1-xTB and GFN2-xTB have internal parameters in the xtb binary which are loaded if no parameter files are found in the XTBPATH or the XTBPATH is not set.

[susilehtola]

Oh, now I understand the problem: even though I've built shared libraries with meson, xtb is not linked to them but rather the libraries are bundled statically in the xtb binary.

The real cause of the problem is that the data files are packaged along with the libraries, which are not pulled in since the binary does not depend on the libraries.

[susilehtola]

So, what I would like to do is change

 xtb_exe = executable(
   meson.project_name(),
   sources: prog,
-  dependencies: xtb_dep_static,
+  dependencies: xtb_dep,
   link_language: 'fortran',
   install: install,
 )

but now the compile fails in

$ ninja
[221/234] Compiling Fortran object xtb.p/src_prog_submodules.f90.o
FAILED: xtb.p/src_prog_submodules.f90.o 
gfortran -Ixtb.p -I. -I.. -I../include -Ilibxtb.so.6.4.1.p -I/usr/lib64/gfortran/modules -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -O2 -fdefault-real-8 -fdefault-double-8 -ffree-line-length-none -fbacktrace -frecursive -fexternal-blas -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -pthread -fopenmp -Jxtb.p -o xtb.p/src_prog_submodules.f90.o -c ../src/prog/submodules.f90
f951: Warning: ‘-Werror=’ argument ‘-Werror=format-security’ is not valid for Fortran
../src/prog/submodules.f90:20:8:

   20 |    use xtb_mctc_accuracy, only : wp
      |        1
Fatal Error: Cannot open module file ‘xtb_mctc_accuracy.mod’ for reading at (1): No such file or directory
compilation terminated.
[222/234] Compiling Fortran object xtb.p/src_prog_argparser.f90.o
FAILED: xtb.p/src_prog_argparser.f90.o 
gfortran -Ixtb.p -I. -I.. -I../include -Ilibxtb.so.6.4.1.p -I/usr/lib64/gfortran/modules -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -O2 -fdefault-real-8 -fdefault-double-8 -ffree-line-length-none -fbacktrace -frecursive -fexternal-blas -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -pthread -fopenmp -Jxtb.p -o xtb.p/src_prog_argparser.f90.o -c ../src/prog/argparser.f90
f951: Warning: ‘-Werror=’ argument ‘-Werror=format-security’ is not valid for Fortran
../src/prog/argparser.f90:20:8:

   20 |    use xtb_mctc_accuracy, only : wp
      |        1
Fatal Error: Cannot open module file ‘xtb_mctc_accuracy.mod’ for reading at (1): No such file or directory
compilation terminated.
ninja: build stopped: subcommand failed.

[awvwgk]

Yes, that is currently not possible the way I setup the targets. I'll look into a different setup removing the intermediate archive, which still allows to easily to statically link the binary and create a separate shared library, as well has have the binary dynamically link the library.

[susilehtola]

I guess I should switch to CMake then....

[awvwgk]

We reproduced the same logic of linking as well in CMake, therefore it has to be refactored in either build system.