renamed GMP symbols in GHC

[Michal Konečný]

Dear all,

Several issues related to the way GMP is included in GHC were publicly discussed in the past with the goal of replacing GMP.  As summarised in this wiki by Peter Tanski, the main issues were:

(1) Licensing
(2) Memory Structure; Simultaneous Access to GMP by Foreign (C) code in the Same Binary.  

My immediate concern is (2) as I develop programs that link with MPFR, which uses GMP.  So far I got around the issue by compiling GHC with integer-simple. This is fine for me but I feel the need to recompile ghc may be hindering some people who would like to try my software that links with MPFR.  I have therefore been looking for a way to overcome (2) that could make it to the default build of GHC.

As suggested by Simon PJ in this email, a simple way to deal with issue (2) is to "*copy* GMP,  changing all the function names".  I recently found some time and had a go at implementing this suggestion and it turned out to be quite easy.  I described my recipe to do such a "copy" here but currently I have been able to test it only on x86 Linux and GHC 7.2.1.

I checked that the renaming makes a difference by running all QuickCheck tests of my AERN-Real-MPFR package.  Some of these tests persistently fail when compiled with a standard GHC.  All tests succeed with GHC/integer-simple and also with GHC 7.2.1 using the renamed GMP.

I was wondering whether such a change (more polished and tested on all common platforms) could make it to the future official GHC releases.  If the GHC developers would support this change, I would be happy to put more work into it.

I think the following concrete changes would be required in the GHC distribution:
(a) make a ghc build always use the bundled GMP
(b) apply a renaming script onto the GMP tar before adding it to the GHC source bundle
(c) rename symbols analogously in integer-gmp/cbits/*

An alternative to (b) is to apply the renaming to the GMP sources just before building it.

One thing I am not clear about is the impact such a change would have on lincensing.  My understanding is that GHC sources include GMP sources and in the absence of an installed GMP library, they are statically linked into the integer-gmp package.  (Does it mean that the integer-gmp package should be LGPL lincensed?)  The suggested changes would mean that this kind of linking would happen always, not only when no other GMP library is available on the system.  In either case, it seems to me that using integer-gmp as a shared library would still be OK for producing non-LGPL code.

I would be grateful for your views and guidance.

Best regards,
Michal
-- 
|o| Michal Konecny <mikkonecny at gmail.com>
|o|    http://www-users.aston.ac.uk/~konecnym/
|o|    office: (+42) (0)121 204 3462 
|o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aston


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20111222/9fef9ed3/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20111222/9fef9ed3/attachment-0001.pgp>