On Mon, 25 Mar 2013, Niels Möller wrote:
Martin Storsjö <[email protected]> writes:
In addition to these, a fallback is needed for mpn_sqr if building
with GMP 4.2.1 (which people who want to stay away from LGPLv3 might
want to do), but that one doesn't seem to be quite as trivial as
these.
I guess the simplest workaround is something like
#define mpn_sqr(rp, ap, n) mpn_mul_n((rp), (ap), (ap), (n))
IIRC, the squaring function is available also in older GMP releases,
under the name mpn_sqr_n, but it was undocumented and intended for
internal use only.
Right, thanks.
At some point, we have to abandon older GMP releases.
Yes, that's quite true. For these cases where the fallback is pretty
simple I'd rather put off requiring the newer version thogh.
As for supporting GPLv2-only applications, I know that GMP developers
have considered doing GPLv2+ and LGPLv3+ dual licensing. People who have
a *real* interest in that (rather than hypotheticals like "some other
people might not like LGPLv3") should contact GMP developers and offer
help and encouragement.
Additionally, I now see that eccdata.c (which is built for the build
system, not for the target) requires GMP [...]
Or would the files produced by eccdata.c be architecture/target
independent?
They're archtecture dependent, depending mainly on GMP_NUMB_BITS on the
target system. One option is to bundle mini-gmp, see
http://gmplib.org:8000/gmp/file/mini-gmp. Or if one is prepared to limit
the support to 32-bit and 64-bit limbs, one could generate tables for
both sizes and include in the tarballs.
Hmm, both solutions do sound pretty sensible - and thanks for the pointer
to mini-gmp. Hooking that up during the cross-builds I mentioned should
possibly be easier than building and installing a full GMP, even if it
isn't included in release tarballs.
// Martin
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
