| > 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. | | http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes 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 eg http://www.haskell.org/pipermail/libraries/2007-August/007909.html * 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. Thanks Peter! * 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. Simon