[SuiteSparse_jll] Update to v7.0.1

[fxcoudert]

This will not work currently, as it requires merging of JuliaPackaging/Yggdrasil#6296 first
This is currently progressing through a full build from source on my machine

[ViralBShah]

SparseArrays.jl needs updates to use the new SuiteSparse as discussed in JuliaSparse/SparseArrays.jl#332. We shouldn't update before that is done, and we bump SparseArrays.jl here.

[fxcoudert]

@ViralBShah fix proposed at JuliaSparse/SparseArrays.jl#353

[ViralBShah]

I've triggered the sparsearrays bump. Once that is in, we can upgrade the other pieces here.

[fxcoudert]

Indeed, will rebase after #48876 and JuliaPackaging/Yggdrasil#6296 are merged

[ViralBShah]

The SparseArrays bump PR is #48876

[fxcoudert]

Now waiting on #48914

[fxcoudert]

┌ Warning: CHOLMOD version incompatibility
  | │
  | │ Julia was compiled with CHOLMOD version 3.0.14. It is
  | │ currently linked with version 4.0.3.
  | │ This might cause Julia to terminate when working with
  | │ sparse matrix factorizations, e.g. solving systems of
  | │ equations with \.
  | │
  | │ It is recommended that you use Julia with the same major
  | │ version of CHOLMOD as the one used during the build, or
  | │ download the generic binaries from www.julialang.org,
  | │ which ship with the correct versions of all dependencies.
  | └ @ SparseArrays.CHOLMOD /cache/build/default-amdci5-7/julialang/juliamaster/usr/share/julia/stdlib/v1.10/SparseArrays/src/solvers/cholmod.jl:199

I have a hard time understanding where that 3.0.14 version comes from.

ERROR: could not load library "libspqr"
  | │    libspqr_cuda.so.3: cannot open shared object file: No such file or directory

😢 see DrTimothyAldenDavis/SuiteSparse#308

It appears that these libraries are actually built on purpose, and their base version link against them. I do not see another choice than to actually link them into the build.

[fxcoudert]

Re. the CHOLMOD version warning. I welcome guidance here, because I really don't understand the update and testing process. I've opened an issue at JuliaSparse/SparseArrays.jl#359 because it appears it should be fixed there. But it's like I'm missing something, because a dependency update needs:

1. an update on Yggdrasil (and publishing of the builds)
2. an update on generated sources in SparseArrays.jl (built against what? unclear to me)
3. an update of the SparseArrays.jl in julia
4. an update of the julia source build

and steps 2 and 3 need to be possibly done multiple times because when SparseArrays.jl is updated, it doesn't fully test julia, so it needs to be iterated until new problems are discovered.

[rayegun]

Regarding unconditional loading of the CUDA SPQR this is somewhat annoying. It means we'll have to rename the actual CUDA binaries...

[ViralBShah]

It's picking up 3.0.14 from julia/stdlib/v1.10/SparseArrays/src/solvers/lib. There is auto-generated wrapper code in SparseArrays.jl/src/solvers/lib, which needs to be updated using the instructions in https://github.com/JuliaSparse/SparseArrays.jl/tree/main/gen

Hopefully going forward the steps 2 and 3 don't need to be repeated too many times now that we have updated the ambiguity detection tests. Perhaps your larger point is that this process needs to be documented. The hope is that we will be able to move SparseArrays.jl out of stdlibs in the next release, which will simplify things greatly.

Because SuiteSparse is part of the stdlib, it gets pinned to the version that ships in Julia. So I believe to run the wrapper script, one has to run it as part of the PR that also bumps SuiteSparse in Julia.

[fxcoudert]

I believe to run the wrapper script, one has to run it as part of the PR that also bumps SuiteSparse in Julia

I have no idea how to do that. Can you point to instructions, or a previous PR?

which needs to be updated using the instructions in https://github.com/JuliaSparse/SparseArrays.jl/tree/main/gen

I have looked at that, but it's a manual process in a different repo. I don't see how I can fit that into the julia PR.

[ViralBShah]

The process has to run in SparseArrays.jl, update the code there, and we run the bump script to pull the updated SparseArrays.jl into Julia master. Then we can rerun this one.

I need to look into why this didn't get detected in SparseArrays.jl tests to begin with.

[fxcoudert]

I need to look into why this didn't get detected in SparseArrays.jl tests to begin with.

What version(s) of SparseSuite is SparseArrays.jl tested against? If it is tied to that in julia, then that would be why, I suppose.

[ViralBShah]

Ok, so here's what is happening:

1. The version of SuiteSparse.jl is decided in Julia master - the files that are updated in this PR.
2. When we update SparseArrays.jl, it uses the nightly build of Julia master in the CI.
3. But when we update julia master here, it has the old version of SparseArrays.jl

The two need to be tested together, which I'll try to do locally, and then push things. These are remnants of our recent efforts to remove SparseArrays from stdlib, and decouple SparseArrays.jl and SuiteSparse.jl (which didn't fully go through successfully).

[ViralBShah]

Carried forward in #48977