ABINIT 8.2.2 + LibXC

[mstud]

LibXC support in the 8.2.2 ABINIT easyconfigs is broken. First, there is a typo in the configure parameter:

configopts = "--with-mpi-prefix=$EBROOTIMPI/intel64 --with-trio-flavor='etsf_io+netcdf' --with-dft=flavor='libxc'

It should be --with-dft-flavor='libxc' instead of --with-dft=flavor='libxc', note the double "=" character. Because of that, LibXC is disabled entirely in the resulting build.

Just fixing this typo does not help, however, because ABINIT 8.2 does not seem to be compatible with LibXC 3.0 yet. It even checks for version 2.2 on configure, which fails because the signature of xc_version has changed in 3.0:

configure:37455: checking whether this is LibXC version 2.2 conftest.c(115): error #165: too few arguments in function call xc_version(&major, &minor); ^

compilation aborted for conftest.c (code 2)

I therefore suggest going back to LibXC 2.2.3 as the dependency, which works perfectly fine.

Edit: nearly forgot, I also had to add -lxcf90 to the --with-libxc-libs parameter.

[fgeorgatos]

Very interesting catch!

It makes you wonder if ldd should be used as part of the build workflow, as part of sanity checks, to verify that dependencies are indeed relied upon.

I recall a similar story of HDF5 lzip (?) dependency, which went undetected for years, until @xbesseron caught it.

Interestingly, ldd check has a worthy side-effect: forcing to expand the sanity tests, until all underlying dependencies are covered... it probably makes much sense, despite the insanity of the work involved!!!

PR anyone?! ;)

F. -- echo "sysadmin know better bash than english"|sed s/min/mins/ \ | sed 's/better bash/bash better/' # signal detected in a CERN forum

[fgeorgatos]

I didn't say explicitly that all dependencies should be visible in the ldd output across several sanity checks. That's the deal. -- echo "sysadmin know better bash than english"|sed s/min/mins/ \ | sed 's/better bash/bash better/' # signal detected in a CERN forum

[boegel]

@migueldiascosta Are you up for looking into fixing this, since it relates to your PR #4397?

[boegel]

@fgeorgatos Having a way of checking whether specified dependencies are really used would be nice, but it's way more complex than just checking the output of ldd.

First, with ldd you'll only see shared libraries, not static libraries. And that's without considering RPATH.

Also, there may be other reasons to list a particular dependency: maybe it provides a binary tool that is required by this software, or a Python package or Perl module, etc.