Support for building as static library

[Chris Hecker]

So I think I’ve posted about this before but I have krb5 building
statically on windows, although it’s a slightly out of date client
version.  It was a bit of a hack job though, and I’ve been afraid to try to
update it to latest to see what needs to be done.  I also have it working
multithreaded on windows, which required some per thread init code.  But it
was possible a few years back at least.

Chris


On Thu, Jun 30, 2022 at 14:30 Ken Hornstein via krbdev <krbdev 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.
>
> FWIW, we used to do this for a very long time, and it mostly worked ...
> except for some weird duplicate symbol names in the admin library, which
> I never submitted a patch for because of the whole "unsupported" thing.
> For that build the libraries were static but the plugins were dynamic.
>
> We eventually had to give this up, because of weird bugs.  Specifically,
> we ran into issues with PKINIT, because (at that time) we linked the
> krb5 library against OpenSSL (which was also a static build) but you
> needed to have the PKINIT plugin ALSO linked against a static copy of
> OpenSSL, and it turns out when you dlopen a plugin that has a copy
> of OpenSSL _and_ you are linked against your own copy of OpenSSL ...
> strange stuff happens.  Like you randomly pick symbols from one library
> or the other during execution, and what happened to us was that one
> code path would initialize _one_ copy of OpenSSL, and then another code
> path would use the _other_, non-initialized OpenSSL and crash (because
> the second OpenSSL would check using the _first_ OpenSSL's variables to
> see if it was initialized or not).  I wouldn't have quite believed this
> would happen until I stepped through the code with a debugger myself.
> It occurs to me now that to make those plugins work we also had to link
> the plugins against the static krb5 libraries which meant there was
> probably two copies of krb5 in the program at the same time and that
> could have caused other problems later.  We ran into these problems on
> Linux (we also built statically on MacOS X but did not encounter the
> specific problem with weird symbol resolution).  It is probable that
> some combination of esoteric linker options could have resolved this
> mess, but switching back to a shared build resolved all of that (that
> caused a round of screaming internally, but at least that was resolved
> relatively quickly).
>
> --Ken
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>