Updating Julia package FLINT_jll to Flint 3.1.0

[Joel Dahne]

Hello!

Has anyone taken a look at updating the Julia package FLINT_jll [1] to
Flint 3.1.0?

I was not sure in which repository to open an issue for this, so I
thought the email list might be the most appropriate.

I have never been involved in this process of updating FLINT_jll before,
so I have no experience with it. I have managed to compile it locally
but I have not been able to load it properly, see the details further
down. I have some questions regarding the update:

- Is the process I have described below correct, or am I missing
something?

- I have seen some discussions in Nemo about issues with Flint 3.0.0,
that version 3.1.0 would possibly fix [2][3]. There seems to be a new
` __flint_set_all_memory_functions` function. Does this require
updates to the init function in FLINT_jll?

- The FLINT_jll package currently reads the NEMO_THREADED variable,
would it make sense to add an alias, e.g. FLINT_THREADED, for this?
There are several other packages making using of Flint and it can seem
a bit odd to have to set a variable refereeing to NEMO if one is not
using NEMO. I must admit I have not fully understood why this variable
is needed, what changes when threading is used.

My attempt at getting it to work locally:

I could get it to compile by making two updates to [4]. Updating
`sources` to

sources = [
GitSource("https://github.com/flintlib/flint.git", "785a6d0048d55fccb6a74c6fb2cf89ac44235d77"), # v3.1.0
]

and `dependencies` to

dependencies = [
Dependency("GMP_jll", v"6.2.1"),
Dependency("MPFR_jll", v"4.2.0"),
Dependency("OpenBLAS32_jll", v"0.3.10"),
]

Note that the version of GMP is bumped from 6.2.0 to 6.2.1 since Flint
now requires it, and the MPFR version is bumped from 4.1.1 to 4.2.0
due to the updated GMP.

Then compiling it with

julia build_tarballs.jl --debug --verbose aarch64-linux

While it seems to compile fine I have not been able to load it properly.
Following the process from [5] I get the error

ERROR: InitError: could not load library "/home/joeldahne/.julia/dev/FLINT_jll/override/lib/libflint.so"
/home/joeldahne/.julia/dev/FLINT_jll/override/lib/libflint.so: cannot open shared object file: No such file or directory
Stacktrace:
[1] dlopen(s::String, flags::UInt32; throw_error::Bool)
...

I think this is an issue with my local configuration though and not the
new Flint version. But I'm not sure how to solve it.

[1]: https://github.com/JuliaBinaryWrappers/FLINT_jll.jl
[2]: https://github.com/Nemocas/Nemo.jl/pull/1568
[3]: https://github.com/flintlib/flint/pull/1734
[4]: https://github.com/JuliaPackaging/Yggdrasil/blob/master/F/FLINT/build_tarballs.jl
[5]: https://docs.binarybuilder.org/stable/building/#Building-a-custom-JLL-package-locally

Best,
Joel

[Albin Ahlbäck]

Tjenixen Joel!

> - I have seen some discussions in Nemo about issues with Flint 3.0.0,
> that version 3.1.0 would possibly fix [2][3]. There seems to be a new
> ` __flint_set_all_memory_functions` function. Does this require
> updates to the init function in FLINT_jll?

No, it does not need updates there. With the `fft_small` module (which
will be included if one compiles for `x86_64-v3` or Arm v8), one needs
an aligned allocation function. Julia, however, do not provide such a
function (see my issue here:
https://github.com/JuliaLang/julia/issues/52901). Hence, the previous
FLINT memory functions still work, but it will provide an aligned
allocation function based on non-aligned allocation functions.

> Then compiling it with
>
> julia build_tarballs.jl --debug --verbose aarch64-linux

Not sure if this is the problem, but you are now supposed to specify the
host triplet.

> While it seems to compile fine I have not been able to load it properly.
> Following the process from [5] I get the error
>
> ERROR: InitError: could not load library
"/home/joeldahne/.julia/dev/FLINT_jll/override/lib/libflint.so"
> /home/joeldahne/.julia/dev/FLINT_jll/override/lib/libflint.so: cannot
open shared object file: No such file or directory
> Stacktrace:
> [1] dlopen(s::String, flags::UInt32; throw_error::Bool)
> ...

Do you get some log that we can follow? It seems like it doesn't produce
the binaries.

Best,
Albin