Support for building as static library

[Thomas Sondergaard]

Thanks for your response. That is all I needed to know. I don’t need static
libs myself, I only needed to know what to do about the static case in the
conan recipe and now I do.

Thanks again,
Thomas

On Thu, 30 Jun 2022 at 20.28, Greg Hudson <ghudson at mit.edu> wrote:

> On 6/30/22 11:57, Thomas Sondergaard wrote:
> > So I thought I'd ask here: What is the state
> > of support for building krb5 as a static library?
>
> It's mostly unsupported.
>
> The addition of library plugin frameworks meant that some core
> functionality (such as KDB modules) is loaded in at runtime via
> dlopen().  That can't work if all of the libraries are built as static.
>  It could potentially work if the plugin libraries are built as shared
> and the core libraries are built as static, but I haven't investigated
> that route.
>
> In 2009 I added very limited support for --enable-static
> --disable-shared, motivated by a lack of support for shared libraries in
> gcov at the time.  This support required significant build system
> contortions to link in the in-tree KDB plugin modules at build time.
> That support doesn't extend to preauth modules and k5tls, so the result
> is a somewhat restricted libkrb5.  gcov has added support for shared
> libraries, so the riginal motivation for the change has disappeared.
>
> I would consider a pull request to remove the current --enable-static
> --disable-shared support, and instead always build shared plugin
> libraries and load them at runtime from static core libraries, if that
> works on modern platforms.  But I don't know if that would meet the
> needs of people who want static library builds.
>