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.
