Ticket History #8968: Building 1.18.3 on OpenBSD 6.8 amd64

# Sat Nov 21 13:19:25 2020 Robert Crowston <crowston@protonmail.com> - Ticket created

Subject:	Building 1.18.3 on OpenBSD 6.8 amd64
To:	"krb5-bugs@mit.edu" <krb5-bugs@mit.edu>
From:	"Robert Crowston" <crowston@protonmail.com>
Date:	Sat, 21 Nov 2020 16:32:48 +0000

Download (untitled) / with headers
text/plain 2.8KiB

(Apologies if this is the wrong list for reporting bugs. Please redirect me to the right list if I am here in error.)

I had to make some changes to the sources to build krb5-1.18.3 on my system.

$ uname -a
OpenBSD virt-openbsd.xxx 6.8 GENERIC.MP#1 amd64

Firstly, gcc on OpenBSD is 4.2.1, now very elderly. By default, ./configure uses gcc if it finds it, but I was not able to compile using gcc. Instead, I used clang, which is the supported compiler for OpenBSD on amd64 and available as 'cc'.

./configure CC=cc CXX=c++

I suggest that ./configure be changed to use clang by default on OpenBSD.

Secondly, ld on OpenBSD amd64 is now ld.lld, the llvm linker, not ld the GNU linker.

$ ld --version
LLD 10.0.1 (compatible with GNU linkers)

For whatever reason, when invoking ld directly, it is not able to find the default libraries in /usr/lib. Instead I modified the shlib.conf script to use the clang driver to run the linker.

--- /dev/fd/11 Sat Nov 21 16:08:26 2020
+++ src/config/shlib.conf Sat Nov 21 12:57:34 2020
@@ -340,7 +340,7 @@
PICFLAGS=-fpic
SHLIBVEXT='.so.$(LIBMAJOR).$(LIBMINOR)'
SHLIBEXT=.so
- LDCOMBINE='ld -Bshareable'
+ LDCOMBINE='$(CC) -shared -fPIC -Wl,-h,$(LIBPREFIX)$(LIBBASE)$(SHLIBVEXT)'
SHLIB_RPATH_FLAGS='-R$(SHLIB_RDIRS)'
SHLIB_EXPFLAGS='$(SHLIB_RPATH_FLAGS) $(SHLIB_DIRS) $(SHLIB_EXPLIBS)'
RPATH_FLAG=-R

I suggest that patch be implemented; there is not a lot of reason to support older versions of OpenBSD.

Thirdly, util/verto expects to be able to link against libm, the math library. However, on OpenBSD, the math functions are part of the native C library and there is no libm. I was able to resolve this by removing lm from SHLIB_EXPLIBS:

--- /dev/fd/11 Sat Nov 21 16:12:43 2020
+++ src/util/verto/Makefile.in Sat Nov 21 12:05:30 2020
@@ -19,7 +19,7 @@
$(OUTPRE)verto-k5ev.$(OBJEXT)
SRCS=verto.c module.c verto-k5ev.c

-SHLIB_EXPLIBS= $(LIBS) -lm # libm needed for ceil() currently.
+SHLIB_EXPLIBS= $(LIBS)

VERTO_HDR=$(BUILDTOP)$(S)include$(S)verto.h

Indeed I believe that OpenBSD is not the only operating system to bundle the math libraries with libc. Therefore I propose that ./configure should detect whether ceil() can be invoked without -lm and only append -lm for platforms that require it.

Fourthly, pkinit seems incompatible with libressl, OpenBSD's replacement for openssl; we are missing some symbols such as OBJ_get0_data() and X509_get_key_usage(). I found that surprising, but I have no use for pkinit so in lieu of investigating I disabled it at configure time.

./configure CC=cc CXX=c++ --disable-pkinit

Until pkinit is properly fixed I suggest --disable-pkinit become the default on OpenBSD.

With these four minor changes I was able to build and install MIT Kerberos 5 1.18.3 on my OpenBSD system. Thank you for your work on this product.

— RHC.

# Sat Nov 21 13:47:39 2020 ghudson@mit.edu (Greg Hudson) - Correspondence added

Download (untitled) / with headers
text/html 1.5KiB

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.

# Sat Nov 21 14:05:44 2020 Robert Crowston <crowston@protonmail.com> - Correspondence added

From:	"Robert Crowston" <crowston@protonmail.com>
Date:	Sat, 21 Nov 2020 19:05:36 +0000
Subject:	Re: [krbdev.mit.edu #8968] Building 1.18.3 on OpenBSD 6.8 amd64
To:	"rt@krbdev.mit.edu" <rt@krbdev.mit.edu>

Download (untitled) / with headers
text/plain 1.8KiB

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:

Show quoted text

> 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.