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.