gmp's memory management

[as49]

I assume ghc allocates the lumps of gmp integers still on ghc's heap, making it impossible (or very awkward) to interface to C libraries that use gmp themselves. Is there a chance that you could use the default memory allocator for lumps starting from ghc 6.4? That would make my life much easier.

Thanks, Axel.

[simonmar]

Logged In: YES 
user_id=48280

It's a known problem that you can't use GMP via the FFI from
your Haskell code in GHC, or use a C library that internally
uses GMP.  We should really use a private version of GMP
with function names that don't overlap, or better still
replace GMP altogether.

I don't think this is going to get fixed for 6.4, I'm afraid.

[sigbjorn]

Logged In: YES 
user_id=232905

It wouldn't be too hard to provide an entry point that let you 
enable/disable the use of GHC's custom allocator functions.

That entry point would be called by FFI wrapper code, either 
as a service by the RTS or manually by user code. Would 
only work in single (OS) threaded code, of course.

[igloo]

See also 601.

[simonpj]

Comment from Benedict Huber

I've been struggling using FFI bindings to libraries which rely on the GNU Mp Bignum library (gmp) - this is apparently a well known problem (#311, [wiki:ReplacingGMPNotes). I do rely on using such libraries, and so started to get it work on MacOsX; no solution was close to being satisfactory however, so I'd like to ask for some advice.

Those two options worked to some extend:

• Create or modify the library in question, so gmp is statically linked and its symbols are hidden. When source code is available, this is relatively easy, altough it requires modification of the build process (which can be a hassle). If a static "ar" archive is available, it is cumbersome (at least on Mac Os X I ran into a lot of troubles using nmedit), but possible. Furthermore, the resulting libraries are bloated, as each of them contains a copy of the GMP; left alone portability issues.

• As suggested an earlier comment, I tried switching the allocator functions when switching to FFI. It worked, but not in GHCi; also, doing it manually is a lot of work, because, as far as I could figure out, it is neccessary to write a wrapper function for every C-function (indirectly) using the gmp.

Furthermore, most of the libraries expose gmp datatypes (mpz_t,mpq_t) in their API. I currently use a little haskell module working on GHC.Exts, but that's propably not a good option from a maintainer's point of view. There are certainly other possibilities, but I couldn't find one which is both maintainable and portable.

I would be very grateful for any advice, or some information on plans for resolving ticket #311. There are some great libraries (like the Parma Polyhedral Library, to pick an example) out there using gmp, and it would be nice if writing bindings to those libs could be simplified.

Thanks, Benedikt Huber

[judahj]

In the following post, Aleš Bizjak suggests the following workaround: use the foreign library's custom memory interface, and allocate with malloc.

 http://www.haskell.org/pipermail/haskell-cafe/2008-October/048812.html

[igloo]

It is now possible to build GHC with a pure Haskell Integer library, so I'm closing this ticket.

[isaacdupree]

It's still a bug/issue for when GHC is built with GMP. Were we planning on switching to non-GMP as default or mandatory? (I think such a change would need more discussion, because some code might use the speed of GMP's algorithms on large numbers.) I guess just having non-gmp as a configure choice is a workaround for these users, although not a perfect or easy workaround

[igloo]

It's also now easy to create alternative integer backends, e.g. using a renamed gmp, or another C integer library. I don't think we intend to do anything else on this front, though.

GMP will remain the default.