| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Signed-off-by: Andrew Clayton <ac@sigsegv.uk>
|
|
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Co-authored-by: Andrew Clayton <a.clayton@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This bumps the minimum required version of njs to 0.9.0
Cc: Sergey A. Osokin <sergey.osokin@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
You asked for a specific compression library, be clear when it isn't
found.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
-Wno-missing-field-initializers was needed for GCC 4.8 / RHEL 7 etc to
avoid warnings with {} empty initialisers.
We haven't needed to support that compiler for sometime.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This allows to actually build unit with support for zlib, zstd and
brotli compression.
Any or all can be specified. E.g.
$ ./configure --zlib ...
$ ./configure --zlib --zstd --brotli ...
During configure you will see if support for the requested compressions
has been found and what version of the library is being used.
E.g.
...
checking for zlib ... found
+ zlib version: 1.3.1.zlib-ng
checking for zstd ... found
+ zstd version: 1.5.6
checking for brotli ... found
+ brotli version: 1.1.0
...
Unit configuration summary:
...
zlib support: .............. YES
zstd support: .............. YES
brotli support: ............ YES
...
Co-authored-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Now that we are able to use the "nonstring" variable attribute to quell
this warning, we no longer need to disable it.
The good thing is there was never a released version of GCC where the
warning couldn't be quelled by the attribute.
Fixes: 150378224 ("Fix build with GCC 15")
Cc: Alejandro Colomar <alx@kernel.org>
Reviewed-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This is a wrapper around __attribute__ ((__nonstring__)). Traditionally
this was used to mark char array variables that intentionally lacked a
terminating NUL byte, this would then cause warning to either be quelled
or emitted for various memory/string functions.
GCC 15 introduced a new warning, Wunterminated-string-initialization,
which will always warn on things like
static const char hex[16] = "0123456789ABCDEF";
However this is very much intentionally not NUL terminated.
When the Wunterminated-string-initialization patch went in, the
"nonstriong" attribute didn't quell this warning, however a patch has
since gone in (prior to the GCC 15 release) to enable this attribute to
quell this warning.
In Unit we disabled this new warning with an eye to being able to
re-enable it again, this patch is the first in a series to do just that.
So the above example would become
static const char hex[16] NXT_NONSTRING = "0123456789ABCDEF";
Link: <https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=44c9403ed1833ae71a59e84f9e37af3182be0df5>
Link: <https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=622968990beee7499e951590258363545b4a3b57>
Link: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178#c21>
Cc: Alejandro Colomar <alx@kernel.org>
Reviewed-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
The upcoming GCC 15 release introduces a new compiler warning,
Wunterminated-string-initialization.
This is intended to catch things like
static const u_char hex[16] = "0123456789ABCDEF";
Where we are creating a character array from a string literal, but the
specified size is not enough for the terminating NUL byte.
In the above example that is intended as it is used as a lookup table
and only the individual indices are accessed.
As it happens, Unit uses the above idiom in a few places, triggering
this warning (which we treat as an error by default).
While I don't like disabling compiler warnings, lets just disable this
one temporarily, as there is a patch in the works to make the
"nonstring" variable attribute quell this warning.
We just disable this on GCC as this isn't in Clang and we don't need to
worry about older compilers as GCC silently ignores unknown -Wno-*
options.
Link: <https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=44c9403ed1833ae71a59e84f9e37af3182be0df5>
Link: <https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Common-Variable-Attributes.html>
Link: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178#c21>
Cc: Alejandro Colomar <alx@kernel.org>
Reviewed-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
There were at least a couple of issues with building OTEL support.
It only worked with GNU make due to the use of ifeq, even gmake had some
issues.
Debug builds were broken due to trying to pass --debug to cargo which is
the default and isn't a valid option.
This 'fixes' things by doing 'release' builds of OTEL by default.
Passing D=1 to make will generate 'debug' builds but this as previously
with D= etc, only works with GNU make.
We make use of the '--emit link=' rustc option to place the libotel.a
static library into build/lib
This is good, it consolidates the static libraries into one place and it
simplifies the build scripts.
While we're at it pretty print the cargo command by default.
Fixes: 9d3dcb800 ("otel: add build tooling to include otel code")
Link: <https://github.com/nginx/unit/pull/1520#issuecomment-2556265063>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Rust code relies on macOS-provided frameworks for TLS.
Fixes: 9d3dcb800 ("otel: add build tooling to include otel code")
[ Tweaked subject prefix. Some minor tweaks for current changes. -
Andrew ]
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Fixes: 9d3dcb800 ("otel: add build tooling to include otel code")
[ Commit subject, s/NXT_OTEL_LIB_LOC/NXT_OTEL_LIB_STATIC/ and placement
of NXT_OTEL_LIB_STATIC tweaked as per @thresheek - Andrew ]
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
The static library is supposed to be specified prior to its
dependencies.
Also, no need to put an otel static library inside libnxt static
library, as we explicitely link unit binary with otel static library
anyway.
This fixes the following build problems:
- macOS:
Finished `release` profile [optimized] target(s) in 58.07s
AR build/lib/libnxt.a
LD build/sbin/unitd
ld: archive member 'libotel.a' not a mach-o file in '/private/tmp/unit-20241219-8965-yb46xp/build/lib/libnxt.a'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
- Ubuntu 22 (./configure --otel):
LD build/sbin/unitd
cc -Wl,-E -o build/sbin/unitd -pipe -fPIC -fvisibility=hidden -fno-strict-overflow -funsigned-char -std=gnu11 -O -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -fno-strict-aliasing -Wmissing-prototypes -Werror -g \
build/src/nxt_main.o build/lib/libnxt.a \
-lm -lrt -lpthread \
\
-lpcre2-8 -lssl -lcrypto src/otel/target/release/libotel.a
/usr/bin/ld: src/otel/target/release/libotel.a(reqwest-97d1376dfb77d784.reqwest.cb371ce8e1e3945e-cgu.04.rcgu.o): in function `core::ptr::drop_in_place<alloc::vec::Vec<reqwest::tls::Certificate>>':
reqwest.cb371ce8e1e3945e-cgu.04:(.text._ZN4core3ptr69drop_in_place$LT$alloc..vec..Vec$LT$reqwest..tls..Certificate$GT$$GT$17h9b62679cc7161be5E+0x30): undefined reference to `X509_free'
Fixes: 9d3dcb800 ("otel: add build tooling to include otel code")
[ Tweaked subject prefix. s/NXT_OTEL_LIB_LOC/NXT_OTEL_LIB_STATIC/ - Andrew ]
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This better matches existing naming convention, e.g NXT_LIB_STATIC
Fixes: 9d3dcb800 ("otel: add build tooling to include otel code")
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
When building with --otel on macOS for example I was seeing compile
failures with the cpu_set_t stuff which should only be used under Linux.
It turned out that despite
checking for Linux sched_getaffinity() ... not found
we were getting
#ifndef NXT_HAVE_LINUX_SCHED_GETAFFINITY
#define NXT_HAVE_LINUX_SCHED_GETAFFINITY 1
#endif
in build/include/nxt_auto_config.h
It seems this was due to the
. auto/feature
in auto/otel, this check happens right after the above. Without having
nxt_feature_name=NXT_HAVE_OTEL
set.
Instead we were adding the define for that manually.
Doing auto/feature without having a nxt_feature_name must have used the
last set one and enabled it.
Set nxt_feature_name and remove the manual editing of nxt_auto_config.h
Fixes: 9d3dcb800 ("otel: add build tooling to include otel code")
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
@thresheek reported an issue trying to configure OTEL support on Amazon
Linux 2
checking for OTEL requirements:
- checking for rust compiler ... found
- checking for cargo ... found
- checking for OpenSSL library ... found
Package openssl was not found in the pkg-config search path.
Perhaps you should add the directory containing `openssl.pc'
to the PKG_CONFIG_PATH environment variable
No package 'openssl' found
We successfully built the test program with '-lssl -lcrypto', but then
tried to use 'pkg-config openssl --cflags --libs' to override
NXT_OTEL_LIBS.
On Amazon Linux2 there is no openssl.pc, they have a openssl11.pc.
Let's just remove the pkg-config check, if we get here, we have
successfully built with '-lssl -lcrypto', so just go with that (it also
matches what we do in auto/ssltls).
Reported-by: Konstantin Pavlov <thresh@nginx.com>
Closes: https://github.com/nginx/unit/issues/1510
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
|
|
Adds the --otel flag to the configure command and the various build time
variables and checks that are needed in this flow.
It also includes the nxt_otel.c and nxt_otel.h files that are needed for
the rest of Unit to talk to the compiled static library that's generated
from the rust crate.
Signed-off-by: Ava Hahn <a.hahn@f5.com>
Co-authored-by: Gabor Javorszky <g.javorszky@f5.com>
Signed-off-by: Gabor Javorszky <g.javorszky@f5.com>
|
|
[ Tweaked subject - Andrew ]
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
When configuring under Linux we always got the following
checking for pthread spinlock zero initial value ... found but is not working
Having *actually* taken a look at this, this check seems somewhat bogus,
the first thing it does is
pthread_spinlock_t lock = 0;
which you shouldn't do anyway, you should use pthread_spin_init(3) to
initialise the pthread_spinlock_t variable.
But in any case, this thing, NXT_HAVE_PTHREAD_SPINLOCK_ZERO, isn't even
checked for in the code.
Neither is NXT_HAVE_PTHREAD_SPINLOCK, we don't use the pthread_spin_*
API, but rather roll our own spinlock implementation.
So let's just remove these checks, at the very least it'll speed
./configure up!
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Due to 'char' (unless explicitly set) being signed or unsigned depending
on architecture, e.g on x86 it's signed, while on Arm it's unsigned,
this can lead to subtle bugs such if you use a plain char as a byte
thinking it's unsigned on all platforms (maybe you live in the world of
Arm).
What we can do is tell the compiler to treat 'char' as unsigned by
default, thus it will be consistent across platforms. Seeing as most of
the time it doesn't matter whether char is signed or unsigned, it
really only matters when you're dealing with 'bytes', which means it
makes sense to default char to unsigned.
The Linux Kernel made this change at the end of 2022.
This will also allow in the future to convert our u_char's to char's
(which will now be unsigned) and pass them directly into the libc
functions for example, without the need for casting.
Here is what the ISO C standard has to say
From §6.2.5 Types ¶15
The three types char, signed char, and unsigned char are collectively
called the character types. The implementation shall define char to
have the same range, representation, and behavior as either signed
char or unsigned char.[45]
and from Footnote 45)
CHAR_MIN, defined in <limits.h>, will have one of the values 0 or
SCHAR_MIN, and this can be used to distinguish the two options.
Irrespective of the choice made, char is a separate type from the
other two and is not compatible with either.
If you're still unsure why you'd want this change...
It was never clear to me, why we used u_char, perhaps that was used as
an alternative to -funsigned-char...
But that still leaves the potential for bugs with char being unsigned vs
signed...
Then because we use u_char but often need to pass such things into libc
(and perhaps other functions) which normally take a 'char' we need to
cast these cases.
So this change brings at least two (or more) benefits
1) Removal of potential for char unsigned vs signed bugs.
2) Removal of a bunch of casts. Reducing casting to the bare minimum
is good. This helps the compiler to do proper type checking.
3) Readability/maintainability, everything is now just char...
What if you want to work with bytes?
Well with char being unsigned (everywhere) you can of course use char.
However it would be much better to use the uint8_t type for that to
clearly signify that intention.
Link: <https://lore.kernel.org/lkml/Y1Bfg06qV0sDiugt@zx2c4.com/>
Link: <https://lore.kernel.org/lkml/20221019203034.3795710-1-Jason@zx2c4.com/>
Link: <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3bc753c06dd02a3517c9b498e3846ebfc94ac3ee>
Link: <https://www.iso-9899.info/n1570.html#6.2.5p15>
Suggested-by: Alejandro Colomar <alx@kernel.org>
Reviewed-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
[ Tweaked subject - Andrew ]
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This will help to better determine the number of router threads to
create in certain situations.
Unlike sysconf(_SC_NPROCESSORS_ONLN) this takes into account per-process
cpu allowed masks as set by sched_setaffinity(2)/cpusets etc.
So while a system may have 64 on-line cpu's, Unit itself may be limited
to using just four of them in which case we should create four extra
router threads, not sixty-four!
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Normally when the language modules are built, they are built directly
into the build/lib/unit/modules/ directory.
This then allows Unit to find them without being installed. This is
useful for things like the pytests.
This wasn't happening for the wasm-wasi-component language module. So we
now copy it over and give it the right name as part of the make/build
process.
Reported-by: Andrei Zeliankou <zelenkov@nginx.com>
Fixes: 4e6d7e876 ("Wasm-wc: Wire it up to the build system")
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
They are more readable.
And we had a mix of both styles; there wasn't really a consistent style.
Tested-by: Andrew Clayton <a.clayton@nginx.com>
Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
|
|
This directory should exist already in the system, and if not, it should
(and will) be created at run time, not at install time.
It triggered a warning in Alpine Linux's packaging system:
ERROR: unit*: Packages must not put anything under /var/run
Fixes: 5a37171f733f ("Added default values for pathnames.")
Fixes: 57fc9201cb91 ("Socket: Created control socket & pid file directories.")
Closes: <https://github.com/nginx/unit/issues/742>
Reported-by: Andy Postnikov <apostnikov@gmail.com>
Tested-by: Andy Postnikov <apostnikov@gmail.com>
Tested-by: Andrew Clayton <a.clayton@nginx.com>
Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
Cc: Liam Crilly <liam@nginx.com>
Cc: Konstantin Pavlov <thresh@nginx.com>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
|
|
Signed-off-by: Arjun <pkillarjun@protonmail.com>
Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
[ Tweaked subject - Andrew ]
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
When we added -fno-strict-overflow to the CFLAGS back in c1e3f02f9
("Compile with -fno-strict-overflow") we inadvertently broke building
the Perl language module with clang, e.g
$ make
CC build/src/perl/nxt_perl_psgi-perl.o
clang: error: argument unused during compilation: '-fno-strict-overflow' [-Werror,-Wunused-command-line-argument]
This is due to for example on Apline
$ perl -MExtUtils::Embed -e ccflags
-D_REENTRANT -D_GNU_SOURCE -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
Where on clang the -fwrapv causes the -fno-strict-overflow to be
discarded resulting in the above error.
We can get around that by simply appending -Qunused-arguments to the
Perl CFLAGS.
This fixes things for _some_ systems, as there is actually another issue
with building this with clang on Fedora (and probably Red Hat) in that
there the Perl ccflags & ldopts have been heavily modified and uses
flags simply not only not in clang (which we can work around as above)
but also incompatible flags, e.g
$ make perl
CC build/src/perl/nxt_perl_psgi-perl.o
clang: error: optimization flag '-ffat-lto-objects' is not supported [-Werror,-Wignored-optimization-argument]
There doesn't seem to be an easy workaround like -Qunused-arguments for
this.
While we could work around it in some way, I'm not sure it's worth the
effort right now. On Red Hat & Fedora GCC _is_ the system compiler.
This could be revisited if we find people trying to build this on
Red Hat/Fedora with clang...
For comparison this is the Alpine Perl ccflags & ldops
$ perl -MExtUtils::Embed -e ccflags
-D_REENTRANT -D_GNU_SOURCE -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 alpine:~$
$ perl -MExtUtils::Embed -e ldopts
-rdynamic -Wl,-rpath,/usr/lib/perl5/core_perl/CORE -fstack-protector-strong -L/usr/local/lib -L/usr/lib/perl5/core_perl/CORE -lperl -lpthread -ldl -lm -lcrypt -lutil -lc
Fedora
$ perl -MExtUtils::Embed -e ccflags
-D_REENTRANT -D_GNU_SOURCE -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fwrapv -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
$ perl -MExtUtils::Embed -e ldopts
-Wl,--enable-new-dtags -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -fstack-protector-strong -L/usr/local/lib -L/usr/lib64/perl5/CORE -lperl -lpthread -lresolv -ldl -lm -lcrypt -lutil -lc
Fixes: c1e3f02f9 ("Compile with -fno-strict-overflow")
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Since commit 0b5223e1c ("Disable strict-aliasing in clang by default")
we explicitly always build with -fno-strict-aliasing so there's no need
to set it independently in auto/modules/wasm
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
|
|
Have cargo run if for example src/wasm-wasi-component/src/lib.rs is
changed, or any of the other files that should perhaps trigger a
rebuild.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Currently Unit doesn't specify any specific C standard for compiling and
will thus be compiled under whatever the compiler happens to default to.
Current releases of GCC and Clang (13.x & 17.x respectively at the time
of writing) default to gnu17 (C17 + GNU extensions).
Our oldest still-supported system is RHEL/CentOS 7, that comes with GCC
4.8.5 which defaults to gnu90.
Up until now this hasn't really been an issue and we have been able to
use some C99 features that are implemented as GNU extensions in older
compilers, e.g
- designated initializers
- flexible array members
- trailing comma in enum declaration (compiles with -std=c89, warns
with -std=c89 -pedantic)
- snprintf(3)
- long long (well we test for it but don't actually use it)
- bool / stdbool.h
- variadic macros
However there are a couple of C99 features that aren't GNU extensions
that would be handy to be able to use, i.e
- The ability to declare variables inside for () loops, e.g
for (int i = 0; ...; ...)
- C99 inline functions (not to be confused with what's available with
-std=gnu89).
However, if we are going to switch up to C99, then perhaps we should
just leap frog to C11 instead (the Linux Kernel did in fact make the
switch from gnu89 to gnu11 in March '22). C17 is perhaps still a little
new and is really just C11 + errata.
GCC 4.8 as in RHEL 7 has *some* support for C11, so while we can make
full use of C99, we couldn't yet make full use of C11, However RHEL 7 is
EOL on June 30th 2024, after which we will no longer have that
restriction and in the meantime we can restrict ourselves to the
supported set of features (or implement fallbacks where appropriate).
It can only be a benefit that we would be compiling Unit consistently
under the same language standard.
This will also help give the impression that Unit is a modern C code
base.
It is also worth noting the following regarding GCC
"A version with corrections integrated was prepared in 2017 and published
in 2018 as ISO/IEC 9899:2018; it is known as C17 and is supported with
-std=c17 or -std=iso9899:2017; the corrections are also applied with -
std=c11, and the only difference between the options is the value of
STDC_VERSION."
Suggested-by: Andrew Clayton <a.clayton@nginx.com>
Acked-by: Andrew Clayton <a.clayton@nginx.com>
[ Andrew wrote the commit message ]
Signed-off-by: Alejandro Colomar <alx@kernel.org>
Link: <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e8c07082a810fbb9db303a2b66b66b8d7e588b53>
Link: <https://www.ibm.com/blog/announcement/ibm-is-announcing-red-hat-enterprise-linux-7-is-going-end-of-support-on-30-june-2024/>
Link: <https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Standards.html#C-Language>
Cc: Dan Callahan <d.callahan@f5.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This change makes NJS module incompatible with NJS older than 0.8.3.
Therefore, the configuration version check has been adjusted accordingly.
This change was introduced in NJS 0.8.3 here:
<https://hg.nginx.com/njs/rev/ad1a7ad3c715>
|
|
This variable is _appended_ to the main CFLAGS variable and allows
setting extra compiler options at make time. E.g
$ make EXTRA_CFLAGS="..." ...
Useful for quickly testing various extra warning flags.
Suggested-by: Alejandro Colomar <alx@kernel.org>
Reviewed-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This adds a help target to the Makefile in the repository root that
shows what variables are available to control the make/build behaviour.
It currently looks like
$ make help
Variables to control make/build behaviour:
make V=1 ... - Enables verbose output
make D=1 ... - Enables debug builds (-O0)
make E=0 ... - Disables -Werror
Variables can be combined.
Reviewed-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Having -Werror enabled all the time when developing can be a nuisance,
allow to disable it by passing E=0 to make, e.g
$ make E=0 ...
This will set -Wno-error overriding the previously set -Werror.
Co-developed-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
One issue you have when trying to debug Unit under say GDB is that at
the default optimisation level we use of -O (-O1) the compiler will
often optimise things out which means they are not available for
inspection in the debugger.
This patch allows you to pass 'D=1' to make, e.g
$ make D=1 ...
Which will set -O0 overriding the previously set -O, basically disabling
optimisations, we could use -Og, but the clang(1) man page says this is
best and it seems to not cause any issues when debugging GCC generated
code.
Co-developed-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This makes use of the infrastructure introduced in a previous commit, to
pretty print the make output when building the wasm language module.
You can still get the old verbose output with
$ make V=1 ...
Reviewed-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This makes use of the infrastructure introduced in a previous commit, to
pretty print the make output when building the Ruby language module.
You can still get the old verbose output with
$ make V=1 ...
Reviewed-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This makes use of the infrastructure introduced in a previous commit, to
pretty print the make output when building the Python language module.
You can still get the old verbose output with
$ make V=1 ...
Reviewed-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This makes use of the infrastructure introduced in a previous commit, to
pretty print the make output when building the PHP language module.
You can still get the old verbose output with
$ make V=1 ...
Reviewed-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This makes use of the infrastructure introduced in a previous commit, to
pretty print the make output when building the Perl language module.
You can still get the old verbose output with
$ make V=1 ...
Reviewed-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This makes use of the infrastructure introduced in a previous commit, to
pretty print the make output when building the Java language module.
You can still get the old verbose output with
$ make V=1 ...
Reviewed-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This makes use of the infrastructure introduced in the previous commit
to pretty print the make output when building the Unit core and the C
test programs.
When building Unit the output now looks like
VER build/include/nxt_version.h (NXT_VERSION)
VER build/include/nxt_version.h (NXT_VERNUM)
CC build/src/nxt_lib.o
CC build/src/nxt_gmtime.o
...
CC build/src/nxt_cgroup.o
AR build/lib/libnxt.a
CC build/src/nxt_main.o
LD build/sbin/unitd
SED build/share/man/man8/unitd.8
I'm sure you'll agree that looks much nicer!
You can still get the old verbose output with
$ make V=1 ...
Reviewed-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
The idea is rather than printing out the full compiler/linker etc
command for each recipe e.g
cc -c -pipe -fPIC -fvisibility=hidden -O0 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wno-strict-aliasing -Wmissing-prototypes -g -I src -I build/include \
\
\
-o build/src/nxt_cgroup.o \
-MMD -MF build/src/nxt_cgroup.dep -MT build/src/nxt_cgroup.o \
src/nxt_cgroup.c
Print a clearer abbreviated message e.g the above becomes
CC build/src/nxt_cgroup.o
This vastly reduces the noise when compiling and most of the time you
don't need to see the full command being executed.
This also means that warnings etc show up much more clearly.
You can still get the old verbose output by passing V=1 to make e.g
$ make V=1 ...
NOTE: With recent versions of make(1) you can get this same, verbose,
behaviour by using the --debug=print option.
This introduces the following message types
CC Compiling a source file to an object file.
AR Producing a static library, .a archive file.
LD Producing a dynamic library, .so DSO, or executable.
VER Writing version information.
SED Running sed(1).
All in all this improves the developer experience.
Subsequent commits will make use of this in the core and modules.
NOTE: This requires GNU make for which we check. On OpenIndiana/illumos
we have to use gmake(1) (GNU make) anyway as the illumos make doesn't
work with our Makefile as it is. Also macOS seems to generally install
GNU make.
We could make it work (probably) on other variants of make, but the
complexity starts increasing exponentially.
In fact we still print the abbreviated messages in the verbose output so
you can still do
$ make | grep ^" [A-Z]"
on other makes to effectively get the same output.
Co-developed-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This causes signed integer & pointer overflow to have a defined
behaviour of wrapping according to two's compliment. I.e INT_MAX will
wrap to INT_MIN and vice versa.
This is mainly to cover existing cases, not an invitation to add more.
Cc: Dan Callahan <d.callahan@f5.com>
Suggested-by: Alejandro Colomar <alx@kernel.org>
Reviewed-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Aliasing is essentially when you access the same memory via different
types.
If the compiler knows this doesn't happen it can make some
optimisations.
There is however code in Unit, for example in the wasm language module
and the websocket code that may fall foul of strict-aliasing rules.
(For the wasm module I explicitly disable it there)
In auto/cc/test for GCC we have
NXT_CFLAGS="$NXT_CFLAGS -O"
...
# -O2 enables -fstrict-aliasing and -fstrict-overflow.
#NXT_CFLAGS="$NXT_CFLAGS -O2"
#NXT_CFLAGS="$NXT_CFLAGS -Wno-strict-aliasing"
So with GCC by default we effectively compile with -fno-strict-aliasing.
For clang we have this
NXT_CFLAGS="$NXT_CFLAGS -O"
...
#NXT_CFLAGS="$NXT_CFLAGS -O2"
...
NXT_CFLAGS="$NXT_CFLAGS -fstrict-aliasing"
(In _clang_, -fstrict-aliasing is always enabled by default)
So in clang we always build with -fstrict-aliasing. I don't think this
is the best idea, building with something as fundamental as this
disabled in one compiler and enabled in another.
This patch adjusts the Clang side of things to match that of GCC. I.e
compile with -fno-strict-aliasing. It also explicitly sets
-fno-strict-aliasing for GCC, which is what we were getting anyway but
lets be explicit about it.
Cc: Dan Callahan <d.callahan@f5.com>
Reviewed-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
