[20386] in Kerberos_V5_Development
Re: Support for building as static library
daemon@ATHENA.MIT.EDU (Thomas Sondergaard)
Thu Jun 30 15:14:20 2022
MIME-Version: 1.0
In-Reply-To: <3b273b13-7765-8085-ae3f-7e631120b0a2@mit.edu>
From: Thomas Sondergaard <thomas@sondergaard.cc>
Date: Thu, 30 Jun 2022 21:12:21 +0200
Message-ID: <CAKxQmMuB_-jfaU2yxHJwm3pT+Eab2jKhSqwB-FKj2f=N3umqFg@mail.gmail.com>
To: Greg Hudson <ghudson@mit.edu>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
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@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.
>
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
