[Debichem-devel] Bug#935994: Bug#935994: nwchem: NWChem compiled with long int lapack/blas interface?

[Mo Zhou]

Hi NWChem maintainers,

blas/lapack lib maintainer here.

> I don't follow it closely, are you saying that both the refblas/lapack
> packages now provide a 64bit int interface, and MKL? Or just MKL?

both. We additionally compiled a 64bit-indexing version of src:lapack,
namely libblas64-dev and liblapack64-dev.

Once built against the standard implementaiton, users could switch
the underlying blas64/lapack64 with the update-alternatives mechanism.
https://wiki.debian.org/DebianScience/LinearAlgebraLibraries

e.g libopenblas64-0 (still in exp), libblis64-2,
libmkl-rt (need to export MKL_INTERFACE_LAYER=ILP64 when actually using)

However I don't recommend compiling debian packages with the
  -lmkl_gf_ilp64 -lmkl_intel_thread -lmkl_core -lmkl_blacs_openmpi_ilp64 ...
way as it would drive the package into contrib.

> Unless there are considerable downsides (are there?) I would not mind
> switching the nwchem packaging to a 64bit int build using blas/lapack
> libraries from main.

There is no known downside for the 32-bit indexing to 64-bit one switch.
According to the user demand, I think keeping a 32-bit indexing version
would not be quite useful, as the same functionality has been delivered
by the 64bit version.

> Regarding mkl, my current, initial opinion is that we would welcome
> patches to make it possible to rebuild nwchem for MKL without source
> changes (via some DEB_BUILD_OPTIONS or other external flags), but
> building nwchem twice and once for MKL would (I believe) mean the source
> package would have to move into contrib as it build-depended on a
> non-free package.

as explained above.