renamed GMP symbols in GHC

[Simon Marlow]

On 22/12/2011 22:58, Michal Konečný wrote:

> 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
> <http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes>, 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
> <http://www.haskell.org/pipermail/glasgow-haskell-users/2006-August/010676.html>,
> 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
> <http://code.google.com/p/hmpfr/wiki/GHCWithRenamedGMP> 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.

Ok, as I understand it this would be fine from a licensing perspective: 
we would be modifying the source, but distributing the modifications 
(either as a patch or a script, it doesn't matter).

One potential problem is that some Linux distributions really don't like 
it if you bundle modified versions of external libraries.  However, I 
just don't see a way around this: GMP is inherently broken because it 
has global state, so if you want two use it from two clients in the same 
program, you need two copies of it.  If these Linux distributions still 
kick up a fuss, then we would have to back off and not bundle the 
modified GMP, but then users of GHC on those distros would have to 
install their own local copy of GHC in order to use MPFR or some other 
GMP client.

Can anyone involved with packaging for Debian or Fedora comment?

Cheers,
	Simon