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>
Expand on the comment on why we don't enable -Wstrict-overflow=5 on GCC.
Link: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96658>
Reviewed-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
This is what -Wextra used to be called, but any version of GCC or Clang
in at least the last decade has -Wextra.
Cc: Dan Callahan <d.callahan@f5.com>
Reviewed-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
We really only support building Unit with GCC and Clang.
Cc: Dan Callahan <d.callahan@f5.com>
Reviewed-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
We really only support building Unit with GCC and Clang.
Cc: Dan Callahan <d.callahan@f5.com>
Reviewed-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
We only really support building Unit with GCC and Clang.
Cc: Dan Callahan <d.callahan@f5.com>
Reviewed-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
We don't run on Windows and only really support compiling Unit with GCC
and Clang.
Cc: Dan Callahan <d.callahan@f5.com>
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 is unused, yet a community member just spent time finding and
fixing a bug in it only to be told it's unused.
Just get rid of the thing.
Link: <https://github.com/nginx/unit/pull/963>
Reviewed-by: Zhidao Hong <z.hong@f5.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
-o is not available on macOS 12.7 at least, and it's what homebrew seems
to support still.
Also, the proposed switch seems to be used already in the codebase.
cargo build creates the language module under
src/wasm-wasi-component/target/release/libwasm_wasi_component.so and not
build/lib/unit/modules/wasm_wasi_component.unit.so which is what we were
using as a target dependency in the Makefile which doesn't exist so this
resulted in the following
$ make wasm-wasi-component-install
cargo build --release --manifest-path src/wasm-wasi-component/Cargo.toml
Finished release [optimized] target(s) in 0.17s
install -d /opt/unit/modules
install -p src/wasm-wasi-component/target/release/libwasm_wasi_component.so \
/opt/unit/modules/wasm_wasi_component.unit.so
I.e it wanted to rebuild the module, after this patch we get the more
correct
$ make wasm-wasi-component-install
install -d /opt/unit/modules
install -p src/wasm-wasi-component/target/release/libwasm_wasi_component.so \
/opt/unit/modules/wasm_wasi_component.unit.so
This is all a little ugly because we're fighting against cargo wanting
to do its own thing and this wasm-wasi-component language module build
process is likely going to get some re-working anyway, so this will do
for now.
Reported-by: Konstantin Pavlov <thresh@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
Rather than calling make itself to build nxt_unit.o make nxt_unit.o a
dependency of the main module build target.
Reported-by: Konstantin Pavlov <thresh@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
A user on GitHub reported an issue when trying to build/install the
nodejs language module.
Doing a
$ ./configure nodejs --node=/usr/bin/node --npm=/usr/bin/npm --node-gyp=/usr/bin/node-gyp
$ make install
was throwing the following error
mv build/src//usr/bin/node/unit-http-g/unit-http-1.31.1.tgz build//usr/bin/node-unit-http-g.tar.gz
mv: cannot move 'build/src//usr/bin/node/unit-http-g/unit-http-1.31.1.tgz' to 'build//usr/bin/node-unit-http-g.tar.gz': No such file or directory
make: *** [build/Makefile:2061: build//usr/bin/node-unit-http-g.tar.gz] Error 1
The fact that we're using the path given by --node= to then use as
directory locations seems erroneous.
But rather than risk breaking existing expectations the simple fix is to
just use build/src in the destination path above to match that of the
source.
These paths were added in some previous commits, and the missing 'src/'
component looks like an oversight.
After this commit both the following work
$ ./configure nodejs --node-gyp=/usr/lib/node_modules/bin/node-gyp-bin/node-gyp --local=/opt/unit/node
$ ./configure nodejs --node=/usr/bin/node --node-gyp=/usr/lib/node_modules/npm/bin/node-gyp-bin/node-gyp --local=/opt/unit/node
Reported-by: ruspaul013 <https://github.com/ruspaul013>
Tested-by: ruspaul013 <https://github.com/ruspaul013>
Fixes: 0ee8de554 ("Fixed Makefile target for NodeJS.")
Fixes: c84948386 ("Node.js: fixing module global installation.")
Reviewed-by: Timo Stark <t.stark@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
This allows to configure the Wasm module, e.g
./configure wasm --include-path=/path/to/wasmtime-v11.0.0-x86_64-linux-c-api/include --lib-path=/path/to/wasmtime-v11.0.0-x86_64-linux-c-api/lib --rpath
--rpath as above says to set the rpath to the value of --lib-path. You
can alternatively specify a directory to use as the rpath. Or simply
omit the option to not have an rpath set.
This is mostly useful for during development where you may not have the
Wasmtime stuff installed to system directories or you want to test with
newer/different versions.
See ./configure wasm --help for a full list of options.
Reviewed-by: Alejandro Colomar <alx@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
This commit introduced the basic URI rewrite. It allows users to change request URI. Note the "rewrite" option ignores the contained query if any and the query from the request is preserverd.
An example:
"routes": [
{
"match": {
"uri": "/v1/test"
},
"action": {
"return": 200
}
},
{
"action": {
"rewrite": "/v1$uri",
"pass": "routes"
}
}
]
Reviewed-by: Alejandro Colomar <alx@nginx.com>
This removes a bunch of unused files that would have been touched by
subsequent commits that switch to using nxt_bool_t (AKA unit6_t) in
structures.
In auto/sources we have
NXT_LIB_SRC0=" \
src/nxt_buf_filter.c \
src/nxt_job_file.c \
src/nxt_stream_module.c \
src/nxt_stream_source.c \
src/nxt_upstream_source.c \
src/nxt_http_source.c \
src/nxt_fastcgi_source.c \
src/nxt_fastcgi_record_parse.c \
\
src/nxt_mem_pool_cleanup.h \
src/nxt_mem_pool_cleanup.c \
"
None of these seem to actually be used anywhere (other than within
themselves). That variable is _not_ referenced anywhere else.
Also remove the unused related header files: src/nxt_buf_filter.h,
src/nxt_fastcgi_source.h, src/nxt_http_source.h, src/nxt_job_file.h,
src/nxt_stream_source.h and src/nxt_upstream_source.h
Also, these files do not seem to be used, no mention under auto/ or build/
src/nxt_file_cache.c
src/nxt_cache.c
src/nxt_job_file_cache.c
src/nxt_cache.h is #included in src/nxt_main.h, but AFAICT is not
actually used.
With all the above removed
$ ./configure --openssl --debug --tests && make -j && make -j tests &&
make libnxt
all builds.
Buildbot passes.
NOTE: You may need to do a 'make clean' before the next build attempt.
Reviewed-by: Alejandro Colomar <alx@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
This makes the build tree more organized, which is good for adding new
stuff. Now, it's useful for example for adding manual pages in man3/,
but it may be useful in the future for example for extending the build
system to run linters (e.g., clang-tidy(1), Clang analyzer, ...) on the
C source code.
Previously, the build tree was quite flat, and looked like this (after
`./configure && make`):
$ tree -I src build
build
├── Makefile
├── autoconf.data
├── autoconf.err
├── echo
├── libnxt.a
├── nxt_auto_config.h
├── nxt_version.h
├── unitd
└── unitd.8
1 directory, 9 files
And after this patch, it looks like this:
$ tree -I src build
build
├── Makefile
├── autoconf.data
├── autoconf.err
├── bin
│ └── echo
├── include
│ ├── nxt_auto_config.h
│ └── nxt_version.h
├── lib
│ ├── libnxt.a
│ └── unit
│ └── modules
├── sbin
│ └── unitd
├── share
│ └── man
│ └── man8
│ └── unitd.8
└── var
├── lib
│ └── unit
├── log
│ └── unit
└── run
└── unit
17 directories, 9 files
It also solves one issue introduced in
5a37171f73 ("Added default values for pathnames."). Before that
commit, it was possible to run unitd from the build system
(`./build/unitd`). Now, since it expects files in a very specific
location, that has been broken. By having a directory structure that
mirrors the installation, it's possible to trick it to believe it's
installed, and run it from there:
$ ./configure --prefix=./build
$ make
$ ./build/sbin/unitd
Fixes: 5a37171f73 ("Added default values for pathnames.")
Reported-by: Liam Crilly <liam@nginx.com>
Reviewed-by: Konstantin Pavlov <thresh@nginx.com>
Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
Cc: Andrei Zeliankou <zelenkov@nginx.com>
Cc: Zhidao Hong <z.hong@f5.com>
Signed-off-by: Alejandro Colomar <alx@nginx.com>
In BSD systems, it's usually </var/db> or some other dir under </var>
that is not </var/lib>, so $statedir is a more generic name. See
hier(7).
Reported-by: Andrei Zeliankou <zelenkov@nginx.com>
Reported-by: Zhidao Hong <z.hong@f5.com>
Reviewed-by: Konstantin Pavlov <thresh@nginx.com>
Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
Cc: Liam Crilly <liam@nginx.com>
Signed-off-by: Alejandro Colomar <alx@nginx.com>
This prctl(2) option can be used to set the "child subreaper" attribute
of the calling process. This allows a process to take on the role of
'init', which means the process will inherit descendant processes when
their immediate parent terminates.
This will be used in an upcoming commit that uses a double fork(2) +
unshare(2) to create a new PID namespace. The parent from the second
fork will terminate leaving the child process to be inherited by 'init'.
Aside from it being better to maintain the parent/child relationships
between the various unit processes, without setting this you need to ^C
twice to fully quit unit when running in the foreground after the double
fork.
Reviewed-by: Alejandro Colomar <alx@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
