oscar-system/loadflint.jl

loadflint.jl's Issues

TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

jl_calloc overflows

julia> ccall(:jl_calloc,Ptr{Nothing},(Csize_t, Csize_t), 0xffffffffffffffff, 0xffffffffffffffff)
Ptr{Nothing} @0x000000001ebd1180

The call may return a non-null value even though it cannot allocate that amount of memory.
JuliaLang/julia#42673

Migration of the code in here to FLINT_jll

BinaryBuilder now has support for inserting code into the __init__ function of JLLs using the init_block kwarg (see JuliaPackaging/BinaryBuilder.jl#791). This also available on Yggdrasil (see JuliaPackaging/Yggdrasil#1260).

With this, in principle we should now be able to move the initialization code in LoadFlint.jl directly into FLINT_jll; fewer moving parts should then make things easier for us.

Right now, though, I have some doubt about how the initialization should look. We do this in LoadFlint.jl right now:

  if !Sys.iswindows() && !__isthreaded[]
    #to match the global gmp ones
    fm = dlsym(libflint_handle, :__flint_set_memory_functions)
    ccall(fm, Nothing,
      (Ptr{Nothing},Ptr{Nothing},Ptr{Nothing},Ptr{Nothing}),
        cglobal(:jl_malloc),
        cglobal(:jl_calloc),
        cglobal(:jl_realloc),
        cglobal(:jl_free))
  end      

What I don't understand is why Windows builds and threaded mode are treated differently. Note that jl_malloc and friends ought to be thread safe (they just wrap malloc etc., plus some code which modifies TLS data).

The threaded check was added by @thofma in Nemocas/Nemo.jl@96663d9

The windows check was added by @wbhart in Nemocas/Nemo.jl@77e6667

Unfortunately in both cases it is not clear what the issues were, so...

Tests fail in Julia 1.0

CI tests recently started to fail with Julia 1.0 because the CI tests end up installing FLINT_jll v2.6.999+0, even though we yanked that version.

My suspicion is that "yanking a version" is not supported in the Pkg.jl bundled with 1.0.

So before we release an update of LoadFlint.j for the new FLINT_jll 200.690, perhaps we should release a minor update of the current version that restricts the version range. This may not be necessary if we are quick in releasing "all" packages using the new FLINT really soon -- but how likely is that...

Use existing binary builders for MPFR?

Perhaps we can use https://github.com/JuliaBinaryWrappers/MPFR_jll.jl/releases which is based on https://github.com/JuliaPackaging/Yggdrasil/blob/master/M/MPFR/build_tarballs.jl ?

(There is also one for MPIR there, but as I understand, we need a patch release beyond MPIR 3.0.0 ? Ah, if only there were MPIR releases...)

Compat entries for next version

Do we agree that the new compat entry for FLINT_jll should be "^200.690.0"?