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.
Xcode 8.3, to which there recently was a switch, spits out a warning for
the potentially unaligned access to ip6_plen in ip-packet.c, which we
explicitly read via untoh16() hence the access to that pointer is not
actually unaligned. It seems the compiler is not able to determine that
there is no unaligned access even though the function is defined in the
header and marked inline.
While d0d85683 works around a crasher related to the use of libunwind, other
build hangs have been seen in the all test cases. Try to
--disable-unwind-backtraces to see if libunwind is really related to those
and if it fixes these issues.
Ubuntu 12.04 does not seem to provide a sane pkg-config for libiptc or libip4tc.
The monolithic build fails due to missing symbols, so disable it until we have
a newer Ubuntu release.
On Ubuntu 12.04, there seems to be a resource leak related to pthread keys
when initializing glib or related libraries more than once. With our repeated
initialization for libstrongswan tests, we hit the following error:
Lib (gthread-posix.c): Unexpected error from C library during
'pthread_key_create': Resource temporarily unavailable.
The problem is not reproducible on a newer Gnome stack, hence we disable the
glib based soup plugin until we have a more recent Ubuntu on Travis.
Travis still uses Ubuntu 12.04, where no systemd libraries are available. Skip
systemd support on Travis until we have a more recent Ubuntu distribution.
But disable the gcrypt plugin, as it causes leaks.
Also disable the backtraces by libunwind as they seem to cause
threads to get cleaned up after the leak detective already has been
disabled, which leads to invalid free()s.
Not sure if 4 jobs is optimal, but according to the docs each build host
has 1.5 virtual cores available (although "getconf _NPROCESSORS_ONLN"
returns 32, which is probably the number of real cores underneath), so
more jobs might not actually reduce the build time much more.