Error while compiling krb 1.5
donn at u.washington.edu
Wed Jul 5 16:17:34 EDT 2006
On Jul 5, 2006, at 12:58 PM, Sam Hartman wrote:
>>>>>> "Russ" == Russ Allbery <rra at stanford.edu> writes:
> Russ> My guess is that most people's static build requirements
> Russ> would be satisfied by a build option that builds both static
> Russ> and shared libraries, still builds all the server code (kdc,
> Russ> kadmind, etc.) against the shared libraries, and only builds
> Russ> the clients against the static libraries. That makes the
> Russ> build machinery more complex, but it sould resolve the
> Russ> plugin problem since I don't expect the clients will need
> Russ> plugins.
> Except that it is likely that GSS mechs will be plugins in 1.6.
In this case, going back to your question,
> * what does it mean to build static? The easiest semantic is that
> you build everything static except that the plugins are still shared.
... I will be wanting an option where the plugins are not shared.
Of course that means they aren't really plugins, which is fine.
For the same reasons as with shared libraries in general, I don't
want applications to depend on plugins.
We do this with Cyrus SASL for OpenLDAP applications. The "plugins",
like libgssapiv2, are put in a static libsasl2.a and linked statically
into the applications.
So I would say the simplest semantic is "you build everything static,
with no exceptions." A mix causes the problems you mention, and doesn't
satisfy the requirements anyway.
Donn Cave, donn at u.washington.edu
More information about the krbdev