Bugs item #1146118, was opened at 2005-02-22 02:34 Message generated for change (Comment added) made by sigbjorn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1146118&group_id=8032
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler (FFI) Group: 6.4 Status: Open Resolution: None Priority: 4 Submitted By: Axel Simon (as49) Assigned to: Nobody/Anonymous (nobody) Summary: gmp's memory management Initial Comment: Simon M, 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. ---------------------------------------------------------------------- >Comment By: Sigbjorn Finne (sigbjorn) Date: 2005-08-23 10:33 Message: 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. ---------------------------------------------------------------------- Comment By: Simon Marlow (simonmar) Date: 2005-02-22 02:49 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1146118&group_id=8032 _______________________________________________ Glasgow-haskell-bugs mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
