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. At some point, we have to abandon older GMP releases. 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. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
