dune-copasi 2 support

[lkeegan]

• function2
  • header only std::function replacement with move-only funcs
• possible extra dune-common deps
  • suitesparse
    • fork with cmake support recommened by ceres
  • metis
    • which also depends on GKLib
  • OpenBLAS for blas/lapack
    • mac has accelerate built-in to the OS so can skip this on mac
    • should check if blas should be serial or parallel here, since there is already a bunch of parallelism in dune-copasi?

[lkeegan]

lapack will be complicated to do correctly on linux/windows:

• we can build static blas & lapack libs using openBLAS
• but the lapack part includes fortran code so the final binary needs to be linked with gfortran and gquadmath
• we can hack the build system to link to libgfortran.a and libgquadmath.a

the above should hopefully work for the compiled binaries, but

• libgfortran.a/libgquadmath.a by default on linux are not compiled with fpic
• this shouldn't matter for linking binaries
• but it does matter for the python library, as we need PIC code to bundle in the shared lib
• two options
  1. link to shared libs for the python wheel build & let cibuildwheel hopefully automatically bundle them
  2. build our own gcc with fpic enabled just for this purpose (seems slightly insane)

[lkeegan]

building gfortran with PIC seems to work at least locally:

../configure --prefix=/opt/gccfpic --disable-shared --with-pic --disable-gcov --disable-multilib --disable-bootstrap --enable-languages=fortran
make -j30
sudo make install

[lkeegan]

Branch with some incomplete attempt at this here: https://github.com/spatial-model-editor/sme_deps_common/tree/gfortran_fpic

Status:

• macos
  • uses accelerate, don't build gfortran or lapack
  • suitesparse seems to compile ok
• linux
  • build gfortran with fpic & static libs
  • can build openblas blas&lapack with this gfortran and clang C compiler
  • can compile suitesparse with these static lapack/gfortran/quadmath libs
  • NOTE: unclear if this is completely safe, as libgfortran links to libstdc++ so we are assuming binary compatibility between the one we compiled for gfortran and the system one that is linked, but so far seems ok
• windows
  • build gfortran with fpic & static libs
  • build openblas blas&lapack with this gfortran and system gcc compiler fails at linking stage
  • best guess is mismatch between libstdc++ compiled by gfortran and system libstdc++

Possible ways forward (in ascending order of unmaintability):

1. don't add suitesparse or any lapack/fortran-dependent libs (i.e. delete this branch)
2. skip gfortran/openblas and only build suitesparse on mac

• make suitesparse an optional build-time dependency of sme, only enable it for mac

3. use system fortran compilers on linux/windows & statically link libgfortran/libquadmath

• pass libs through to sme build & enable suitesparse
• disable suitesparse & do not link these libs in sme wheel build (not PIC -> can't link in shared lib)

4. use custom linux gfortran, need to pass lapack/gfortran libs all the way to sme build, but then can use them in the wheel
5. try to do this on windows

• either by fiddling with patches & config options when building gfortran such that it links with the system libstdc++
• or by modifying the recipe for gcc & building our own complete fpic gcc msys2 toolchain