Build failure on FreeBSD 14
Sp1l opened this issue · 13 comments
As reported on FreeBSD Bugzilla. Same issue with 3.6 branch.
Tried to find a "royal" way of fixing this, like in ef2d6c7 but have no CURRENT or 14 system at my disposal.
configure apparently detects endian.h (-DHAVE_ENDIAN_H=1) yet fails to include it. Resulting in error:
libtool: compile: cc -DPACKAGE_NAME=\"libressl\" -DPACKAGE_TARNAME=\"libressl\" -DPACKAGE_VERSION=\"3.5.3\" "-DPACKAGE_STRING=\"libressl 3.5.3\"" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"libressl\" -DVERSION=\"3.5.3\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DSIZEOF_TIME_T=8 -DHAVE_SYMLINK=1 -DHAVE_ENDIAN_H=1 -DHAVE_ERR_H=1 -DHAVE_READPASSPHRASE_H=1 -DHAVE_NETINET_IP_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_NETINET_IN_H=1 -DHAVE_ARPA_NAMESER_H=1 -DHAVE_NETDB_H=1 -DHAVE_RESOLV_H=1 -DHAVE_ASPRINTF=1 -DHAVE_MEMMEM=1 -DHAVE_READPASSPHRASE=1 -DHAVE_REALLOCARRAY=1 -DHAVE_STRLCAT=1 -DHAVE_STRLCPY=1 -DHAVE_STRNDUP=1 -DHAVE_STRNLEN=1 -DHAVE_STRSEP=1 -DHAVE_STRTONUM=1 -DHAVE_TIMEGM=1 -DHAVE_GETPROGNAME=1 -DHAVE_SYSLOG=1 -DHAVE_ACCEPT4=1 -DHAVE_PIPE2=1 -DHAVE_POLL=1 -DHAVE_SOCKETPAIR=1 -DHAVE_ARC4RANDOM=1
-DHAVE_ARC4RANDOM_BUF=1 -DHAVE_ARC4RANDOM_UNIFORM=1 -DHAVE_EXPLICIT_BZERO=1 -DHAVE_TIMINGSAFE_BCMP=1 -DHAVE_TIMINGSAFE_MEMCMP=1 -DHAVE_DL_ITERATE_PHDR=1 -DHAVE_CLOCK_GETTIME=1 -DHAVE_VA_COPY=1 -DHAVE___VA_COPY=1 -DHAS_GNU_WARNING_LONG=1 -I. -I../include -I../include/compat -DLIBRESSL_INTERNAL -D__BEGIN_HIDDEN_DECLS= -D__END_HIDDEN_DECLS= -I../crypto/bio -D_FORTIFY_SOURCE=2 -O2 -pipe -fpic -DPIC -Wl,-rpath,/usr/local/lib -Wl,--as-needed -fstack-protector-strong -fno-strict-aliasing -Wall -std=gnu99 -fno-strict-aliasing -fno-strict-overflow -fstack-protector-strong -DHAVE_GNU_STACK -Qunused-arguments -Wno-pointer-sign -MT d1_pkt.lo -MD -MP -MF .deps/d1_pkt.Tpo -c d1_pkt.c -fPIC -DPIC -o .libs/d1_pkt.o
d1_pkt.c:138:8: error: use of undeclared identifier 'BYTE_ORDER'
if (BYTE_ORDER == LITTLE_ENDIAN)
^
d1_pkt.c:138:22: error: use of undeclared identifier 'LITTLE_ENDIAN'
if (BYTE_ORDER == LITTLE_ENDIAN)
^
2 errors generated.
*** Error code 1
Stop.
make[3]: stopped in /usr/ports/security/libressl/work-default/libressl-3.5.3/ssl
*** Error code 1
Stop.
make[2]: stopped in /usr/ports/security/libressl/work-default/libressl-3.5.3
*** Error code 1
Stop.
make[1]: stopped in /usr/ports/security/libressl
*** Error code 1
Stop.
make: stopped in /usr/ports/security/libressl
FWIW that particular piece of code - if (BYTE_ORDER == LITTLE_ENDIAN) - has been that way since 2014 . On both OpenBSD and Linux, the /usr/include/endian.h header provides both of these defines. It would appear that FreeBSD added an endian.h, however it only provides underscore and double underscore versions (ironically, the code above was changed in 2014 to remove the underscore prefixes for better compatibility). I'm not sure how this worked on FreeBSD previously - presumably these defines were available via another header?
The following may also be useful/relevant:
http://www.opengroup.org/austin/docs/austin_514.txt
https://www.austingroupbugs.net/view.php?id=162
For now, the easiest/quickest fix is probably to patch d1_pkt.c to either use underscore prefixes, or to add two defines that map these names to the underscore prefixed versions. You'll presumably also run into more of these across most of libcrypto.
FreeBSD 13-stable hit the same issue, for the reason you mentioned.
What sounds strange is that this single code
#include <stdio.h>
#include <endian.h>
int main()
{
if (BYTE_ORDER == LITTLE_ENDIAN)
printf("LE\n");
else
printf("BE\n");
}
compiles and runs correctly using FreeBSD 13-Stable.
But, it fails to compile if endian.h is included at the first place !?
A totally agree with that, probably other ports may have issues with same reason.
A bit strange that at least OpenSSL does not have one.
Other crypto libs and media codecs also must rely on BYTE_ORDER LITTLE_ENDIAN but seems work fine.
I need fix for libressl right now to continue use my desktops and servers.
This patch for peoples like me.
@rozhuk-im
I agree. It sounds clear that the endian.h integration is not working as expected.
It's then a FreeBSD issue, IMHO.
We do not see same issues in other ports@FreeBSD. (or ports maintainers fix it before I found)
It may well be that the the other ports still relies on sys/endian.h or machine/endian.h, as endian.h is quite new.
I guess that libressl's build detects automatically the availability of endian.h and compile against it instead of the former ones.
Looks like this is confirmed as an issue in FreeBSD, see https://reviews.freebsd.org/D39176
@rozhuk-im @DavidMarec Have you tested the proposed changes for base? I'll see if it works when I switch to HAVE_ENDIAN_H in https://github.com/Sp1l/LibreBSD/blob/releng/13.2/secure/lib/libcrypto/Makefile.inc.libressl#L24
@Sp1l , Yes, libressl tests passed successfully with the patch from warner losh.
I'll see if it works when I switch to
HAVE_ENDIAN_Hin https://github.com/Sp1l/LibreBSD/blob/releng/13.2/secure/lib/libcrypto/Makefile.inc.libressl#L24
HAVE_ENDIAN_H will be automatically set by CMake, as it somehow checks for the availability of the endian.h file. The FreeBSD port doesn't rely on CMake by defaut, but on the autotools.
HAVE_ENDIAN_H will be automatically set by CMake, as it somehow checks for the availability of the
endian.hfile. The FreeBSD port doesn't rely on CMake by defaut, but on the autotools.
The autotools also check for endian.h and machine/endian.h. Issue is/was that HAVE_ENDIAN_H included <endian.h> which wasn't working as per standard.
I don't want to pull in CMake as a build dep for any port I maintain.
Fixed with FreeBSD src commit https://cgit.freebsd.org/src/commit/?id=ed52baf51bd142b5e32701842346452a7ebe37a5
Will track 13.2, assume it will be merged before 13.2-RELEASE.
Thanks all!