[16672] in Kerberos-V5-bugs
Re: [krbdev.mit.edu #8968] Building 1.18.3 on OpenBSD 6.8 amd64
daemon@ATHENA.MIT.EDU (Robert Crowston via RT)
Sat Nov 21 14:06:04 2020
From: "Robert Crowston via RT" <rt@krbdev.mit.edu>
In-Reply-To: <r650Wy-XGklRvJ7Bu8rndSbBFPQ7qQz7Irz_pBSwLoAwuFKPC5WeP5VmO27Ha_fg5PkxSdT-m3H9IR7Vk7cRPl9tAff3LyqQuZFnNr5fQ7M=@protonmail.com>
Message-ID: <rt-4.4.4-14673-1605985544-1253.8968-5-0@mit.edu>
To: "AdminCc of krbdev.mit.edu Ticket #8968":;
Date: Sat, 21 Nov 2020 14:05:44 -0500
MIME-Version: 1.0
Reply-To: rt@krbdev.mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: krb5-bugs-bounces@mit.edu
Content-Transfer-Encoding: 8bit
<URL: https://krbdev.mit.edu/rt/Ticket/Display.html?id=8968 >
Actually, I think I confused myself because of the ld problems: after implementing points 2, 3, 4 of my original mail, I can build with ./configure --disable-pkinit.
— RHC.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, 21 November 2020 18:47, Greg Hudson via RT <rt@krbdev.mit.edu> wrote:
> Thanks for this writeup.
>
> What goes wrong when trying to build with gcc? Although I prefer clang over
> gcc, I don't know if there's a great path forward here. autoconf (as a Gnu
> project) is unlikely to stop preferring gcc. There are thousands of
> autoconf-using source distributions, and for each one of them to add its own
> per-platform decisions about the default compiler would be inefficient and
> unreliable.
>
> Changing shlib.conf to use $(CC) -shared is probably good. I note that NetBSD
> uses LDCOMBINE='$(CC) -shared' (no other flags); I don't know if there's a
> reason for the discrepancy with Linux platforms.
>
> I would ordinarily expect that if a platform implements libm functions in libc
> that it would leave behind a stub libm, since -lm has a long history. But a
> configure test is appropriate now that there is an example of a platform that
> chose not to do that.
>
> The PKINIT LibreSSL incompatibility comes about mainly because LibreSSL defines
> OPENSSL_VERSION_NUMBER to 0x20000000L, essentially declaring itself to be
> OpenSSL 2.0, while having no interest in maintaining compatibility with
> OpenSSL's API changes (or even some of its pre-existing features, such as CMS).
> People have written PKINIT patches to work around this, but it's really
> inelegant, and the rough consensus has been to push back against LibreSSL's bad
> practice here rather than accept it. I think it would be reasonable for
> configure to detect whether libcrypto comes from LibreSSL and disable PKINIT.
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
