2

On the page for the Haskell MPFR bindings HMPFR, they explain that in order to use the library one has to recompile ghc with modifications -- either with a different integer library or by renaming a bunch of symbols associated with gmp:

https://code.google.com/p/hmpfr/

https://code.google.com/p/hmpfr/wiki/GHCWithRenamedGMP

Since there is no canonical place to ask questions on the hmpfr page, I'm hoping someone here will be able to answer. What is the current status of this issue? The above modifications are tested with GHC 7.6.1. Are they still needed in GHC 7.8, and will they be needed in 7.10? Will the official version of GHC ever be modified to fix this incompatibility?

davidsd
  • 771
  • 4
  • 18

1 Answers1

2

According to the release notes of GHC 7.10.1, libraries that rely on GMP no longer require special hacks.

The integer-gmp package has been completely rewritten from the ground up. The primary change in this rewrite is that GHC-compiled programs that link to GMP no longer 'hook' GMP allocation routines, to create an Integer on the raw Haskell heap. Instead, integer-gmp now allocates all memory in Haskell code, and talks to GMP via normal FFI imports like other C code.

The practical side effect of this is that C libraries which bind to GMP (such as MPFR or FLINT) no longer need careful (or impossible) hacks to be used inside a GHC-compiled program via the FFI; GMP is treated just like any other C library, with no special accomodations.

In other words, IIUC, it used to be that GHC Integers would be created by calling the appropriate GMP functions that were specifically instructed to allocate memory through GHC. This was a problem because any other library creating a GMP integer would inadvertently have its integers collected by the GC. With the new changes, GHC allocates the memory itself for big integers in Haskell, so there are no longer any special interactions with GMP that affect other users of GMP.

Community
  • 1
  • 1
Kirill
  • 470
  • 3
  • 13