suitesparse: Update to 7.0.1, fix DESTDIR bug

[mkoeppe]

(from #34203 comment:34)

[suitesparse-5.10.1] gcc -std=c99 -L/Users/mkoeppe/s/sage/sage-rebasing/local/lib -Wl,-rpath,/Users/mkoeppe/s/sage/sage-rebasing/local/lib  -L/Users/mkoeppe/s/sage/sage-rebasing/local/var/tmp/sage/build/suitesparse-5.10.1/inst/Users/mkoeppe/s/sage/sage-rebasing/local/lib -L/Users/mkoeppe/s/sage/sage-rebasing/local/var/tmp/sage/build/suitesparse-5.10.1/inst/Users/mkoeppe/s/sage/sage-rebasing/local/lib -L/Users/mkoeppe/s/sage/sage-rebasing/local/var/tmp/sage/build/suitesparse-5.10.1/inst/Users/mkoeppe/s/sage/sage-rebasing/local/lib -L/Users/mkoeppe/s/sage/sage-rebasing/local/var/tmp/sage/build/suitesparse-5.10.1/inst/Users/mkoeppe/s/sage/sage-rebasing/local/var/tmp/sage/build/suitesparse-5.10.1/src/lib -dynamiclib -compatibility_version 1 -current_version 1.0.2 -Wl,-install_name -Wl,/Users/mkoeppe/s/sage/sage-rebasing/local/var/tmp/sage/build/suitesparse-5.10.1/src/lib/libsliplu.1.dylib -shared -undefined dynamic_lookup slip_matrix_div.o slip_create_mpq_array.o SLIP_free.o SLIP_LU_factorize.o SLIP_realloc.o slip_matrix_mul.o slip_get_largest_pivot.o slip_ref_triangular_solve.o SLIP_backslash.o slip_create_mpz_array.o slip_get_nonzero_pivot.o SLIP_LU_solve.o slip_back_sub.o slip_cumsum.o slip_get_pivot.o SLIP_malloc.o slip_sparse_collapse.o SLIP_calloc.o slip_dfs.o slip_get_smallest_pivot.o SLIP_matrix_allocate.o slip_sparse_realloc.o slip_cast_array.o slip_expand_double_array.o SLIP_gmp.o SLIP_matrix_copy.o SLIP_matrix_check.o slip_cast_matrix.o slip_expand_mpfr_array.o SLIP_initialize.o SLIP_matrix_free.o slip_check_solution.o slip_expand_mpq_array.o SLIP_initialize_expert.o SLIP_matrix_nnz.o SLIP_create_default_options.o SLIP_finalize.o SLIP_LU_analysis_free.o slip_permute_x.o slip_permute_b.o slip_create_mpfr_array.o slip_forward_sub.o SLIP_LU_analyze.o slip_reach.o -o /Users/mkoeppe/s/sage/sage-rebasing/local/var/tmp/sage/build/suitesparse-5.10.1/inst/Users/mkoeppe/s/sage/sage-rebasing/local/var/tmp/sage/build/suitesparse-5.10.1/src/lib/libsliplu.1.0.2.dylib -lm -rpath /Users/mkoeppe/s/sage/sage-rebasing/local/var/tmp/sage/build/suitesparse-5.10.1/inst/Users/mkoeppe/s/sage/sage-rebasing/local/var/tmp/sage/build/suitesparse-5.10.1/src/lib -lsuitesparseconfig -lamd -lcolamd -lm -lgmp -lmpfr

DESTDIR is used twice in the -o.

DESTDIR handling is coming from build/pkgs/suitesparse/patches/03-buildflags.patch

We upgrade to 5.12.0 and pick up a fresh set of patches from Debian or another distro

Depends on #34746 Depends on #34835

CC: @kiwifb

Component: packages: standard

Author: François Bissey

Branch/Commit: u/mkoeppe/suitesparse6.0.1 @ 424cb49

Issue created by migration from https://trac.sagemath.org/ticket/34206

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 552fd83 to 2e7881d

[mkoeppe]

Changed branch from u/fbissey/suitesparse6.0.1 to u/mkoeppe/suitesparse6.0.1

[mkoeppe]

comment:43

pushed this commit to address comment:29

---

New commits:

6f4032e

build/pkgs/cmake/spkg-configure.m4: Require version >= 3.22

[mkoeppe]

Changed commit from 2e7881d to 6f4032e

[kiwifb]

comment:44

Forgot about doing that thanks.

[mkoeppe]

comment:45

Adding #34835 as it will make the test builds quicker

[mkoeppe]

Changed dependencies from #34746 to #34746, #34835

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. New commits:

e6bb8e6	build/pkgs/openblas/dependencies: Remove python
41d66d5	Merge #34835

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 6f4032e to 41d66d5

[mkoeppe]

comment:47

Replying to François Bissey:

I wonder if it has to do with

-- Detecting Fortran/C Interface
Failed to compile

When cmake is run to configure cholmod. It looks like we are trying to mix C and Fortran and it is failing.

Yes, I think that's the problem

[kiwifb]

comment:48

The only thing I can think about is that openblas was compiled with a different gfortran but it feels far fetched.

[mkoeppe]

comment:49

In one of the failing builds, I see the following in SuiteSparse_config/build/CMakeFiles/CMakeError.log:

[100%] Linking Fortran executable FortranCInterface
lto1: internal compiler error: compiler does not support ZSTD LTO compression
0x9c311c lto_end_uncompression(lto_compression_stream*, lto_compression)
    ../../src/gcc/lto-compress.cc:411
0x9c1910 lto_get_section_data(lto_file_decl_data*, lto_section_type, char const*, int, unsigned long*, bool)
    ../../src/gcc/lto-section-in.cc:168
0x6929c5 lto_file_finalize
    ../../src/gcc/lto/lto-common.cc:2264
0x6929c5 lto_create_files_from_ids
    ../../src/gcc/lto/lto-common.cc:2282
0x6929c5 lto_file_read
    ../../src/gcc/lto/lto-common.cc:2337
0x6929c5 read_cgraph_and_symbols(unsigned int, char const**)
    ../../src/gcc/lto/lto-common.cc:2785
0x680312 lto_main()
    ../../src/gcc/lto/lto.cc:626
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
lto-wrapper: fatal error: /sage/local/bin/gfortran returned 1 exit status
compilation terminated.

[mkoeppe]

comment:50

In the failing configurations, we are using system gcc but our own gfortran. This may be a mismatch between them regarding zstd support.

[kiwifb]

comment:51

Yes, it starts making much more sense.

[kiwifb]

comment:52

But there should be other similar failures potentially - at least you would think, since this is also tested in autoconf packages as soon blas/lapack is mixed with C code.

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. New commits:

d3544fe

build/pkgs/zstd: New (gcc/gfortran dependency)

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 41d66d5 to d3544fe

[mkoeppe]

comment:54

Let's try this

[kiwifb]

comment:55

If it works, I'll have to re-enable "supernodal" in cholmod.

[mkoeppe]

comment:56

running at https://github.com/mkoeppe/SuiteSparse/actions/runs/3674049225

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from d3544fe to 63c0139

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. New commits:

63c0139

build/pkgs/zstd: Only require zstd when gcc/gfortran are to be built

[mkoeppe]

comment:58

still failing - https://github.com/mkoeppe/SuiteSparse/actions/runs/3674049225/jobs/6211825144

[mkoeppe]

comment:59

in the failing build, gfortran still does not list zstd as a supported compression algorithm:

/sage/local/bin/gfortran -v
Using built-in specs.
COLLECT_GCC=/sage/local/bin/gfortran
COLLECT_LTO_WRAPPER=/sage/local/libexec/gcc/x86_64-pc-linux-gnu/12.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../src/configure --prefix=/sage/local --with-local-prefix=/sage/local --with-system-zlib --without-isl --disable-multilib --disable-nls --disable-libitm --disable-bootstrap --enable-languages=fortran --disable-darwin-at-rpath   CXX=g++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.2.0 (GCC) 

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 63c0139 to 424cb49

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. New commits:

424cb49

build/pkgs/zstd/spkg-install.in: Also install header

[kiwifb]

comment:61

In gentoo we just seem to do make -C lib install. Although there is also a make -C lib libzstd.pc during the build phase.

[kiwifb]

comment:62

Installing zstd may not be enough, you may have to tell gcc's configure to use it --with-zstd. But really, we want to match the support from the host gcc. So, it may be more complicated to achieve.

[mkoeppe]

comment:63

gfortran is now configured correctly

# local/bin/gfortran -v
Using built-in specs.
COLLECT_GCC=local/bin/gfortran
COLLECT_LTO_WRAPPER=/sage/local/libexec/gcc/x86_64-pc-linux-gnu/12.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../src/configure --prefix=/sage/local --with-local-prefix=/sage/local --with-system-zlib --without-isl --disable-multilib --disable-nls --disable-libitm --disable-bootstrap --enable-languages=fortran --disable-darwin-at-rpath   CXX=g++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (GCC) 

[mkoeppe]

comment:64

Replying to François Bissey:

we want to match the support from the host gcc. So, it may be more complicated to achieve.

Quite possible that this is needed, yes

[mkoeppe]

comment:65

suitesparse still fails to build.

comment:49 has changed - getting a different error now

# cat SuiteSparse_config/build/CMakeFiles/CMakeError.log
make[6]: Entering directory '/sage/local/var/tmp/sage/build/suitesparse-git/src/SuiteSparse_config/build/CMakeFiles/FortranCInterface'
make[6]: Leaving directory '/sage/local/var/tmp/sage/build/suitesparse-git/src/SuiteSparse_config/build/CMakeFiles/FortranCInterface'
make[6]: Entering directory '/sage/local/var/tmp/sage/build/suitesparse-git/src/SuiteSparse_config/build/CMakeFiles/FortranCInterface'
[ 92%] Building Fortran object CMakeFiles/FortranCInterface.dir/main.F.o
[ 94%] Building Fortran object CMakeFiles/FortranCInterface.dir/call_sub.f.o
[ 97%] Building Fortran object CMakeFiles/FortranCInterface.dir/call_mod.f90.o
[100%] Linking Fortran executable FortranCInterface
lto1: internal compiler error: bytecode stream: expected tag LTO_function instead of LTO_eh_table
0x9b4cc1 lto_tag_check
    ../../src/gcc/lto-streamer.h:1028
0x9b4cc1 input_function
    ../../src/gcc/lto-streamer-in.cc:1361
0x9b4cc1 lto_read_body_or_constructor
    ../../src/gcc/lto-streamer-in.cc:1621
0x7020ce cgraph_node::get_untransformed_body()
    ../../src/gcc/cgraph.cc:4011
0x70c48d cgraph_node::expand()
    ../../src/gcc/cgraphunit.cc:1806
0x70c48d cgraph_node::expand()
    ../../src/gcc/cgraphunit.cc:1788
0x70da4e expand_all_functions
    ../../src/gcc/cgraphunit.cc:1999
0x70da4e symbol_table::compile()
    ../../src/gcc/cgraphunit.cc:2349
0x680901 lto_main()
    ../../src/gcc/lto/lto.cc:657
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
make[7]: *** [/tmp/ccL3cCy7.mk:2: /tmp/cc63Hwwl.ltrans0.ltrans.o] Error 1

[mkoeppe]

comment:66

This will need more work on another day

[kiwifb]

comment:68

I have given it some thoughts. bookworm and sid are the only you report failing at this stage. It looks to me that they are both using gcc-12.2.0+patches - gentoo currently similarly ship gcc-12.2.1_pre20221210, some kind of pre-release. It seems it has incompatibilities with earlier gcc/gfortran releases, at least in debian. And our gcc/gfortran is an earlier and official release. I don't see a way out of this that doesn't forbid this version of the compiler unless there are both gcc and gfortran installed.

[mkoeppe]

comment:69

I agree, the Debian patches are likely the cause for the incompatibility. I think the LTO data comes with a version annotation, and Debian should probably have bumped the version along with their patches.

(We also carry a patch, for macOS M1/M2 support, but I don't think it is the problem here.)