Status of GHC runtime dependency on GNU multi precision
simonpj at microsoft.com
Wed Aug 22 05:32:36 EDT 2007
| > I know this is a sensitive issue and I absolutely don't want to start any
| > kind of discussion about the merits or otherwise of LGPL, but I was
| > wondering if there are any plans to remove the GNU mp library from the
| > runtime so that it would be possible to distribute native executables
| > compiled with GHC without having to deal with the additional issues raised
| > by the current inclusion of this LGPL component in the runtime. (Afaik
| > everything else in ghc is under a BSD3 license.)
| There is an interest in removing GMP, motivated partly by licensing but
| also due to portabiltity concerns and the fact that the use of GHC's
| memory manager in GMP prevents FFI code from using GMP safely.
Just to summarise our position at GHC HQ on this question:
* We don't much like bundling GMP either. But it works and it's fast.
* We'd be very happy to have others work on a replacement
(a) using a another C library
(b) using a Haskell library
* Another alternative (c) to be able to build GHC two ways,
- with GMP (fast, but with GMP)
- with a Haskell library instead (probably slower
but no GMP)
Or perhaps arrange that GHC can generate code either
assuming GMP or not assuming GMP (i.e. one compiler with
a flag). BUT it's fiddly and painful to implement and
maintain two paths.
* To replace GMP altogether we'd need to be convinced that
we would not lose much performance.
* There are one or two arbitrary precision libraries in Haskell
* Peter Tanksi did quite a lot of work on (a), but we're not
sure how far he's got. The Wiki link above is his work.
* This is a fiddly topic. GMP is connected to GHC in an unusually
intimate way (because it allocates in GHC's heap). Care needed.
In short, we just don't have the bandwidth to tackle this, but
would be happy to help others who would like to. Although fiddly,
it's a very clear topic for a project.
More information about the Glasgow-haskell-users