renamed GMP symbols in GHC

[Joachim Breitner]

[Fullquote for the benefit of those on the Debian Haskell list.]

Dear Simon,

Am Mittwoch, den 04.01.2012, 12:21 +0000 schrieb 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?

I guess this means me... Indeed Debian has the policy to avoid modified
bundled libraries, if somehow possible. For example, we patch the build
system to use the system-provided libffi.

If you say that GMP is broken, maybe there is a way to fix it proper?
E.g. patch GMP (upstream) to provide an API where the state is explicit
passed in the function argument, so that GHC can keep its GMP state
separate from other clients, which could continue to use the default
global state? Is there at least an upstream bug report about this issue
– maybe upstream can help us out here?

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nomeata at debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata at joachim-breitner.de | http://people.debian.org/~nomeata
-------------- 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/20120104/acc1a219/attachment.pgp>