The build system is a bit limited, only the repository directory and
LGTM_WORKSPACE is writable. sudo doesn't work at all, for others we
don't have enough permission.
IBM Z is big-endian, IBM Power runs in little-endian mode.
Botan requires a fix for issues with GCC and amalgamation enabled (target
pragma ‘*’ is invalid) on ARM64 and IBM Power, while wolfSSL can't be
compiled successfully on IBM Z without an additional patch.
libunwind is not available for x390x, but since we explicitly disable
such backtraces it's not necessary anyway.
This reverts commit 1806ba0890bc503df3dacf01992ec1bca2b0fbb0 as the
workaround is not required anymore and now actually fails because
pre-installed tools have a dependency on libtool.
Do two full build tests on 16.04 (xenial) and the two for OpenSSL 1.0
also run there. Since 18.04 ships OpenSSL 1.1.1, which conflicts with
our custom built version, we skip that until OpenSSL 3.0 is released.
A workaround is required for an issue with sonarqube on bionic.
Check for wolfssl/options.h because if it isn't included, checking other
headers will trigger a warning about hardening the wolfSSL build, which
will cause the check to fail with -Werror.
If the file doesn't exist because user_settings.h is used, the check may
be skipped by configuring with `ac_cv_header_wolfssl_options_h=yes`.
On Nov 12, the scanner was updated and now takes a lot more time (about
3 times as much). Using two threads reduces it a bit (by about 25%).
Using even more threads doesn't help or even increases the time again.
This merges all source files into botan_all.cpp, which reduces the build
time by almost 50%. Building outside the strongSwan tree avoids analyzing
Botan with sonarqube.
This requires config changes if filelog is used with a path that
contains dots. This path must now be defined in the `path` setting of an
arbitrarily named subsection of `filelog`. Without that change the
whole strongswan.conf file will fail to load, which some users might
not notice immediately.
For some reason the clang binary that's installed in an uncommon
directory could not be found anymore when installing packages via pip for
the last couple of builds. While the directory is obviously contained in PATH,
using `sudo -E` didn't help. So we now install the Python packages in the
user's home directory to avoid having to use sudo.
