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?

> nisse@lysator.liu.se (Niels Möller) skribis:
>
>> To try that out, I'm working with a slightly patched guile:
>
> Do you still have the patch around?

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.

>> 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 may also
need some way of figuring out if they need to link with -lgmp or not.

>> 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.

mpz_t is a typedef, which is a single element array of a semi-internal
struct. So when you declare

  mpz_t x;

you are really declaring a struct, not a pointer (and then the array
type automatically "decays" to a pointer when passed as a function
argument).

But it's likely that mini-gmp will use the same size of that struct. And
even the same layout. I think the main ABI incompatibilities are that

1. symbol names, as seen by the linker, are different. With gmp, mpz_foo
   is a name mangling #define, and the real name is ___gmpz_foo.
   mini-gmp doesn't do that.

2. mp_limb_t may be of different size: With mini-gmp, it's always
   unsigned long, with gmp it's unsigned long long on some platforms
   (notably 64-bit windows, I think).

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.

>> 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.

Please also note that the most recent version of mini-gmp is now the one
included in the main gmp repo.