problems with --enable-shared

[James Ralston]

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