linking libkres.so fails on GNU/freebsd systems due to missing htobe32
The debian kfreebsd-amd64 build daemon shows failure to link libknot.so:
cc -fPIE -Dlibknot_SONAME=\"libknot.so.7\" -Dlibzscanner_SONAME=\"libzscanner.so.1\" -DROOTHINTS=\"/usr/share/dns/root.hints\" -DLIBEXT=\".so\" -DLUA_HAS_SETFUNCS="1" -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -Wall -pedantic -fno-omit-frame-pointer -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 -std=c99 -D_GNU_SOURCE -Wno-unused -Wtype-limits -Wformat -Wformat-security -Wall -I/<<PKGBUILDDIR>> -I/<<PKGBUILDDIR>>/lib/generic -I/<<PKGBUILDDIR>>/contrib -DPACKAGE_VERSION="\"2.3.0\"" -DPREFIX="\"/usr\"" -DMODULEDIR="\"/usr/lib/knot-resolver\"" -fvisibility=hidden -I/usr/include/p11-kit-1 -I/usr/include/luajit-2.1 -I/usr/include/p11-kit-1 -Icontrib/ccan/compiler -Icontrib/ccan/ilog -Icontrib/ccan/isaac -Icontrib/ccan/json -Icontrib/ccan/asprintf -Icontrib/murmurhash3 -DENABLE_COOKIES daemon/io.o daemon/network.o daemon/engine.o daemon/worker.o daemon/bindings.o daemon/ffimodule.o daemon/tls.o daemon/tls_ephemeral_credentials.o daemon/zimport.o daemon/main.o -o daemon/kresd -pie -L/<<PKGBUILDDIR>>/lib -lkres /<<PKGBUILDDIR>>/contrib/contrib.a -lknot -lzscanner -ldnssec -luv -lrt -lpthread -lnsl -lkvm -ldl -lluajit-5.1 -lgnutls -specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pthread -lm -Wl,--export-dynamic -Wl,-z,relro,-z,now
/<<PKGBUILDDIR>>/lib/libkres.so: undefined reference to `htobe32'
collect2: error: ld returned 1 exit status
daemon/daemon.mk:51: recipe for target 'daemon/kresd' failed
the htobe32 manpage says:
These functions are nonstandard. Similar functions are present on the BSDs, where the
required header file is <sys/endian.h> instead of <endian.h>. Unfortunately, NetBSD,
FreeBSD, and glibc haven't followed the original OpenBSD naming convention for these func-
tions, whereby the nn component always appears at the end of the function name (thus, for
example, in NetBSD, FreeBSD, and glibc, the equivalent of OpenBSDs "betoh32" is
"be32toh").
since it's still glibc on GNU/freebsd systems, though, i'm not sure why it's not working there.