gmp's memory management
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.
Relates to
Activity
mentioned in issue #601 (closed)
added FFI Tbug Trac import labels
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.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.See also #601 (closed).
Trac metadata
Trac field Value Operating system - → Unknown Architecture - → Unknown 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 (closed), [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 onGHC.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 (closed). 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
changed milestone to %6.10 branch
unassigned @trac-nobody
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
changed milestone to %6.12 branch
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
See #9281 (closed) for a new attempt to improve the situation for the
integer-gmpTrac metadata
Trac field Value TypeOfFailure - → OtherFailure Related - → #9281 (closed) added Plow label
