bug#10519: guile and (mini-)gmp

[ludo@gnu.org (Ludovic Courtès)]

Hi Niels,

nisse@lysator.liu.se (Niels Möller) skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Reviving the discussion, as we’ve been discussing this at the GHM, and
>> some people would really like to see it happen.  :-)
>
> Great! Any summary of the discussion, for those of us who couldn't make
> it there?

Mostly a few people reaffirmed the need for this.

> I'm attaching a patch from I tree I have around, without reading it
> carefully. I'm not sure this is the latest version I worked with. Maybe
> it's of some use.

Yes, thanks.  I just tried it, and here’s the status:

  - numbers.c uses ‘GMP_NUMB_BITS’, which is lacking;
  - it also still uses mpq’s, as Mark noted;
  - random.c uses ‘mpz_realloc2’, also lacking.

>>> 1. The header file libguile.h. As far as I understand, this is a public
>>>    header file and it's use of <gmp.h> means that the public guile ABI
>>>    depends on gmp.
>>
>> The problem is that there’s a public API dealing with mpz_t:
>
> Exactly. To me, that seems like a potentially hairy problem to get
> right.
>
>>   SCM_API void scm_to_mpz (SCM x, mpz_t rop);
>>   SCM_API SCM  scm_from_mpz (mpz_t rop);
>>
>> So, when mini-gmp is used, a <gmp.h> header should be installed as well,
>> say under <libguile/mini-gmp.h>.  WDYT?
>
> Maybe it would make sense with a level of indirection. User's could
> include libguile/bignum.h, which would in turn include either mini-gmp.h
> or the real gmp.h, depending on how guile was configured.

Users are only supposed to include <libguile.h>; headers under
libguile/ aren’t meant to be included directly.

Currently including <libguile.h> pulls <gmp.h>.  When mini-GMP is used
instead, then <libguile/mini-gmp.h> would be pulled instead,
transparently.

> Users may also need some way of figuring out if they need to link with
> -lgmp or not.

libguile-2.0.la and guile-2.0.pc would provide that info.

>>> Since mini-gmp is not binary compatible,
>>
>> I don’t think there’s a problem, because only mpz_t objects appear in
>> the API, and they’re pointers.

[...]

> Hmm, or if you're saying that the use of mpz_t in guile's public API is
> pointers only, that that might make things a little simpler. But things
> will still break badly if the user's code is linked with gmp and guile
> uses mini-gmp, or vice versa.

Exactly, that’s the only case where it would break, AFAICS.  And it’s
probably an unlikely use case: users who want to use both GMP and Guile
surely have libguile linked against GMP.

>>> 4. mini-gmp has no mp_set_memory_functions.
>
> That's added now, with the subtle difference that mini-gmp doesn't pass
> a valid size for the old_size argument for the free and realloc
> functions. I don't think guile depends on that feature.

No, it doesn’t.

I’m slightly concerned about mini-gmp, though.  It’s almost 5000 lines,
mostly copied from GMP AIUI, but with no way to synchronize.  How do you
consider the maintenance cost of this?

I understand some people want this, and I’m happy you’re helping, but
the amount of work and duplication involved would definitely be a
showstopper for me if you and Mark weren’t helping.

Thanks,
Ludo’.