On Mon, 25 Mar 2013, Niels Möller wrote:
Martin Storsjö martin@martin.st 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