Let's make clear which commands goes into the wolfSSL directory and
which one in the haproxy directory. Also, let's add a paragraph in the
QUIC section explaining how to proceed with wolfSSL.
In the errors and warnings section about common issues, it's useful to
mention the strict-aliasing warning that was happening with gcc-4.4 that
may still be found on old systems, especially since it will probably take
ages to build there and the warning is harmless.
Gcc 13 is known to work, OpenSSL 3.1 and wolfSSL as well. Add a few
hints about build errors when using QUIC + OpenSSL and warnings about
the dramatic OpenSSL 3.x performance regression.
OpenSSL 3.0 is now supported but was not mentioned. Also, it was
found that OpenSSL 0.9.8 doesn't build anymore since 2.5 due to
some of the functions used in the JWT token processing, and since
nobody complained, it seems it's not worth fixing it so support for
it was removed.
It turns out that gcc-3.4 doesn't build anymore (and it has probably been
the case since 2.4 or so). gcc-4.2 does build fine though, let's mark it
as the oldest supported one. Now that gcc-12 works, also update the most
recently known-to-work version.
SSL engines used to be built by default for a long time but they're now
disabled consecutive to the API change that makes OpenSSL 3.0 spew plenty
of warnings. Support may still be enabled by passing USE_ENGINE=1.
This enumerates a few of the options that are expected to have an effect
on the process' self-checks at the expense of more or less performance,
and how to choose sets of options for different deployments.
With a single process, we don't need to USE_PRIVATE_CACHE, USE_FUTEX
nor USE_PTHREAD_PSHARED anymore. Let's only keep the basic spinlock
to lock between threads.
This adds the following CPUs to the makefile:
- armv81 : modern ARM cores (Cortex A55/A75/A76/A78/X1, Neoverse, Graviton2)
- a72 : ARM Cortex-A72 or A73 (e.g. RPi4, Odroid N2, VIM3, AWS Graviton)
- a53 : ARM Cortex-A53 or any of its successors in 64-bit mode (e.g. RPi3)
- armv8-auto: both older and newer ARMv8 cores, with a minor runtime penalty
The reasons for these ones are:
- a53 is the common denominator of all of its successors, and does
support CRC32 which is used by the gzip compression, that the generic
armv8-a does not ;
- a72 supports the same features but is an out-of-order one that deserves
better optimizations; it's found in a number of high-performance
multi-core CPUs mainly oriented towards I/O and network processing
(Armada 8040, NXP LX2160A, AWS Graviton), and more recently the
Raspberry Pi 4. The A73 found in VIM3 and Odroid-N2 can use the same
optimizations ;
- armv81 is for generic ARMv8.1-A and above, automatically enables LSE
atomics which are way more scalable, and CRC32. This one covers modern
ARMv8 cores such as Cortex A55/A75/A76/A77/A78/X1 and the Neoverse
family such as found in AWS's Graviton2. The LSE instructions are
essential for large numbers of cores (8 and above).
- armv8-auto dynamically enables support for LSE extensions when
detected while still being compatible with older cores. There is a
small performance penalty in doing this (~3%) but a same executable
will perform optimally on a wider range of hardware. This should be
the best option for distros. It requires gcc-10 or gcc-9.4 and above.
When no CPU is specified, GCC version 10.2 and above will automatically
implement the wrapper used to detect the LSE extensions.
Now that SLZ is merged, let's update the makefile and compression
files to use it. As a result, SLZ_INC and SLZ_LIB are neither defined
nor used anymore.
USE_SLZ is enabled by default ("USE_SLZ=default") and can be disabled
by passing "USE_SLZ=" or by enabling USE_ZLIB=1.
The doc was updated to reflect the changes.
Solaris 9 (released 2002) added support for closefrom().
I bumped the version in the comment to 10 as the default feature
flags already has event ports enabled which were introduced in
Solaris 10.
Other users are using musl, namely on Docker. It builds fine with
linux-glibc-legacy but not linux-glibc, which needs to first disable
USE_BACKTRACE. Better add a valid entry for it instead of hacking
around another libc.
As haproxy wont build on AIX 7.2 using the old "aix52" TARGET a new
TARGET was introduced which adds two special CFLAGS to prevent the
loading of AIXs xmem.h and var.h. This is done by defining the
corresponding include-guards _H_XMEM and _H_VAR. Without excluding
those headers-files the build fails because of redefinition errors:
1)
CC src/mux_fcgi.o
In file included from /usr/include/sys/uio.h:90,
from /opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/8.3.0/include-fixed/sys/socket.h:104,
from include/common/compat.h:32,
from include/common/cfgparse.h:25,
from src/mux_fcgi.c:13:
src/mux_fcgi.c:204:13: error: expected ':', ',', ';', '}' or '__attribute__' before '.' token
struct ist rem_addr;
^~~~~~~~
2)
CC src/cfgparse-listen.o
In file included from include/types/arg.h:31,
from include/types/acl.h:29,
from include/types/proxy.h:41,
from include/proto/log.h:34,
from include/common/cfgparse.h:30,
from src/mux_h2.c:13:
include/types/vars.h:30:8: error: redefinition of 'struct var'
struct var {
^~~
Futhermore, to enable multithreading via USE_THREAD, the atomic
library was added to the LDFLAGS. Finally, two new CPUs were added
to simplify the usage of power8 and power9 optimizations.
This TARGET was only tested on GCC 8.3 and may or may not work on
IBM's native C-compiler (XLC).
Should be backported to 2.1.
These are some errors met when trying to build with gcc 3.4 on an
old (13 years-old) Solaris 10 and on an even older Linux 2.4 with
glibc 2.2.5. A few options were enough to fix the build there.
The INSTALL guide, the Lua doc and the Prometheus exporter's README all
used to reference "linux2628", "linux26" or even "linux". These were all
updated to consistently reflect "linux-glibc" instead. The default options
were updated there as well so that it should build cleanly on most distros.
