Support for building as static library
thomas at sondergaard.cc
Thu Jun 30 15:12:21 EDT 2022
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.
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.
More information about the krbdev