Support for building as static library

[Ken Hornstein]

>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