We've been introducing a 64 bit-build for the computational stack.
This refers mainly to 64-bit indexing, enabling computation of
extremely large systems (billions of degrees of freedom)

Some packages are already 64-bit enabled, including BLAS, PETSc.

SuiteSparse handles the 64-bit question by defining SuiteSparse_long
(and using idx_t with metis). If I understand the SuiteSparse
configuration correctly, this means a specific configuration option
doesn't need to be set for SuiteSparse to compute large systems.

But as part of the 64-bit computation stack in Debian, we'd need to
provide a separate suitesparse64 build in order to link suitesparse
against blas64 or metis64. (I'm assuming this is a thing we would want
to do in the context of 64-bit computation).

This affects cholmod, for instance, in the sense that cholmod uses
idx_t defined in metis.h.  IDXTYPEWIDTH is the quantity in metis.h
which we'll need to set to 64, in order to provide 64-bit Metis (this
is requested in Bug#961183).

Once metis64 is available, we'll be free to provide suitesparse64
i.e. libsuitesparse64-dev (it might be that header files can be
transferred to a libsuitesparse-common-dev to share with
libsuitesparse-dev),
libcholmod64-3 (or similar), etc.

Once suitesparse64 is available, we'll be able link it from petsc64,
which is currently linking to the standard build of suitesparse.

Drew

libcholmod3 and libspqr2 and libumfpack5 seem to be the only
SuiteSparse components directly affected by the 64-bit numerical
library stack, by linking to libblas.so.3 and liblapack.so.3.
libcholmod3 also links to libmetis5, and libspqr2 and libumfpack5
link to libcholmod3.

Not sure if this makes the packaging easier or harder.
Should libspqr64-2 link to libamd64-2 or to libamd2 ?
Should libamd64-2 be provided if it's identical to libamd2 ?

Hi Drew,

Thanks for the proposal. Just for your information,
there is a WIP branch on suitesparse64:
https://salsa.debian.org/science-team/suitesparse/-/commits/lumin

I just ... ummm ... need some time to finish it.
Of course, any help would be appreciated.

Thanks Mo, good to see the work is started already.

Drew
...

I'm working on a major update to the SuiteSparse build system, which uses
cmake exclusively.  See the dev2 branch
on the SuiteSparse github.  I have a very slightly modified version of
metis, and I compile it
under the name libsuitesparse_metis.so.  It compiles metis with
IDXTYPEWIDTH of 64.

I no longer use SuiteSparse_long, but just int64_t in its place.  That
makes the build more predictable.

This change might resolve this bug.  The dev2 branch is still in progress
but it's getting close.