--On Thursday, December 12, 2002 09:31:07 +0100 Niels Möller nisse@lysator.liu.se wrote:
If it avoided the inclusion of "gmp.h", and the program *uses* some rsa function, then it would just fail at link time instead. GMP is needed for rsa.
But --disable-public-key doesn't make it so that GMP isn't needed, and configure won't abort if it fails to detect GMP.
I don't have any strong opinions on whether GMP is needed. But if it *is* needed, then configure should die if it can't find GMP, rather than giving the builder the illusion that typing "make" can actually succeed. ;)
If you write a program that uses only the symmetric functions of nettle (i.e. no rsa), and you link dynamically, and nettle was compiled with public key support, then you need to link with GMP as well, even if it won't be used. With static linking, only object files that are referred to are dragged into the executable, so if one doesn't call any (function in some) object file that in turn calls GMP, there's no need to link with GMP. Dynamic linking doesn't look at individual object files, it's an all-or-nothing thing.
True; this is the price one pays for the advantages gained by dynamic linking.
Suggestions on how to improve this situation is appreciated.
Alas, I know of no easy solution.
The general "solution" (and I use that term lightly) for this problem is to isolate the functions that have dependencies on other libraries in another (separate) library; e.g., libnettle and libnettle_pubkey. But in the vast majority of cases, this "solution" is far more trouble than it's worth.
On the bright side, modern packaging systems (RPM, .deb, et. al.) tend to push the responsibility of dealing with stacked dynamic linking dependencies onto the packager, and away from end users of the package.
James