summaryrefslogtreecommitdiffhomepage
path: root/auto (follow)
AgeCommit message (Collapse)AuthorFilesLines
2024-03-09Add a help target to the root MakefileAndrew Clayton1-0/+10
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>
2024-03-09Allow to disable -Werror at 'make' timeAndrew Clayton1-0/+8
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>
2024-03-09Enable optional 'debuggable' buildsAndrew Clayton2-2/+11
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>
2024-03-09Pretty print the wasm language module compiler outputAndrew Clayton1-3/+5
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>
2024-03-09Pretty print the Ruby language module compiler outputAndrew Clayton1-3/+5
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>
2024-03-09Pretty print the Python language module compiler outputAndrew Clayton1-3/+5
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>
2024-03-09Pretty print the PHP language module compiler outputAndrew Clayton1-2/+4
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>
2024-03-09Pretty print the Perl language module compiler outputAndrew Clayton1-3/+5
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>
2024-03-09Pretty print the Java language module compiler outputAndrew Clayton1-3/+5
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>
2024-03-09Hook up make pretty printing to the Unit core and testsAndrew Clayton1-20/+40
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>
2024-03-09Add initial infrastructure for pretty printing make outputAndrew Clayton1-0/+29
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>
2024-03-09Compile with -fno-strict-overflowAndrew Clayton1-0/+4
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>
2024-03-09Disable strict-aliasing in clang by defaultAndrew Clayton1-2/+4
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>
2024-03-09Expand the comment about -Wstrict-overflow on GCCAndrew Clayton1-1/+3
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>
2024-03-09Remove -W from compiler flagsAndrew Clayton1-2/+2
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>
2024-03-09Remove support for Sun's Sun Studio/SunPro C compilerAndrew Clayton3-65/+0
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>
2024-03-09Remove support for IBM's XL C compilerAndrew Clayton2-73/+0
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>
2024-03-09Remove support for Intel's icc compilerAndrew Clayton1-11/+0
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>
2024-03-09Remove support for Microsoft's Visual C++ compilerAndrew Clayton1-12/+0
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>
2024-03-05Remove unused nxt_vector_t APIAndrew Clayton1-1/+0
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>
2024-02-27Wasm-wc: use more common uname switch to get operating system nameKonstantin Pavlov1-1/+1
-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.
2024-02-22Update third-party java components to their recent versionsSergey A. Osokin2-14/+14
Acked-by: Timo Stark <t.stark@nginx.com> [ Remove trailing '.' from subject line - Andrew ] Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-02-22Wasm-wc: Use the cargo build output as the make target dependencyAndrew Clayton1-3/+5
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>
2024-02-22Wasm-wc: Add nxt_unit.o as a dependency in the auto scriptAndrew Clayton1-2/+1
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>
2024-02-21Wasm-wc: Wire it up to the build systemAndrew Clayton3-0/+128
Et voila... $ ./configure wasm-wasi-component configuring wasm-wasi-component module Looking for rust compiler ... found. Looking for cargo ... found. + wasm-wasi-component module: wasm_wasi_component.unit.so $ make install test -d /opt/unit/sbin || install -d /opt/unit/sbin install -p build/sbin/unitd /opt/unit/sbin/ test -d /opt/unit/state || install -d /opt/unit/state test -d /opt/unit || install -d /opt/unit test -d /opt/unit || install -d /opt/unit test -d /opt/unit/share/man/man8 || install -d /opt/unit/sh man/man8 install -p -m644 build/share/man/man8/unitd.8 /opt/unit/share/ma n8/ make build/src/nxt_unit.o make[1]: Entering directory '/home/andrew/src/unit' make[1]: 'build/src/nxt_unit.o' is up to date. make[1]: Leaving directory '/home/andrew/src/unit' cargo build --release --manifest-path src/wasm-wasi-component/Cargo.toml Finished release [optimized] target(s) in 0.55s 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 Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-02-21Fix alignment of wasm options text in auto/helpAndrew Clayton1-2/+2
The indentation uses spaces and not TABs. Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-02-20Updated copyright notice.Andrei Zeliankou1-1/+1
2024-02-19Node.js: Build/install fixAndrew Clayton1-2/+2
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>
2024-01-16White space formatting fixesAndrei Zeliankou1-2/+2
Closes: <https://github.com/nginx/unit/pull/1062>
2023-11-29Update third-party components for the Java module.Sergey A. Osokin2-12/+12
2023-10-17Update third-party components for the Java module.Sergey A. Osokin2-10/+10
2023-10-10Update third-party components for the Java module.Sergey A. Osokin2-14/+14
2023-10-06Update third-party components for the Java module.Sergey A. Osokin2-16/+16
2023-08-01Added unit pkg-config file.Konstantin Pavlov4-1/+38
2023-08-17Wasm: Wire the Wasm language module up to the build system.Andrew Clayton3-0/+214
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>
2023-08-09HTTP: controlling response headers support.Zhidao HONG1-0/+1
2023-07-11NJS: explicitely require 0.8.0 or later versions in configure.Konstantin Pavlov1-1/+5
2023-07-07Update third-party components for Unit's Java module.Sergey A. Osokin2-16/+16
2023-05-08NJS: supported loadable modules.Zhidao HONG1-1/+1
2023-04-20HTTP: added basic URI rewrite.Zhidao HONG1-0/+1
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>
2023-05-08Docs: moved uintd.8 to man8/ subdirectory.Alejandro Colomar1-2/+2
Reviewed-by: Artem Konev <a.konev@f5.com> Signed-off-by: Alejandro Colomar <alx@nginx.com>
2023-04-24Remove a bunch of dead code.Andrew Clayton1-13/+0
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>
2023-03-29Auto: mirroring installation structure in build tree.Alejandro Colomar11-91/+85
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 5a37171f733f ("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: 5a37171f733f ("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>
2023-03-29Renamed --libstatedir to --statedir.Alejandro Colomar4-9/+9
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>
2023-02-17Enable the PR_SET_CHILD_SUBREAPER prctl(2) option on Linux.Andrew Clayton1-0/+13
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>
2023-02-17Isolation: Rename NXT_HAVE_CLONE -> NXT_HAVE_LINUX_NS.Andrew Clayton2-8/+8
Due to the need to replace our use of clone/__NR_clone on Linux with fork(2)/unshare(2) for enabling Linux namespaces(7) to keep the pthreads(7) API working. Let's rename NXT_HAVE_CLONE to NXT_HAVE_LINUX_NS, i.e name it after the feature, not how it's implemented, then in future if we change how we do namespaces again we don't have to rename this. Reviewed-by: Alejandro Colomar <alx@nginx.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2023-02-17Isolation: Fix the enablement of PR_SET_NO_NEW_PRIVS.Andrew Clayton1-1/+1
This prctl(2) option is checked for in auto/isolation, unfortunately due to a typo this feature has never been enabled. In the auto/isolation script the feature name was down as NXT_HAVE_PR_SET_NO_NEW_PRIVS0, which means we end up with the following in build/nxt_auto_config.h #ifndef NXT_HAVE_PR_SET_NO_NEW_PRIVS0 #define NXT_HAVE_PR_SET_NO_NEW_PRIVS0 1 #endif Whereas everywhere else is checking for NXT_HAVE_PR_SET_NO_NEW_PRIVS. This also guards the inclusion of sys/prctl.h in src/nxt_process.c which is required by a subsequent commit. Fixes: e2b53e1 ("Added "rootfs" feature.") Reviewed-by: Alejandro Colomar <alx@nginx.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2023-01-31Added default values for pathnames.Alejandro Colomar10-124/+120
This allows one to simply run `./configure` and expect it to produce sane defaults for an install. Previously, without specifying `--prefix=...`, `make install` would simply fail, recommending to set `--prefix` or `DESTDIR`, but that recommendation was incomplete at best, since it didn't set many of the subdirs needed for a good organization. Setting `DESTDIR` was even worse, since that shouldn't even affect an installation (it is required to be transparent to the installation). /usr/local is the historic Unix standard path to use for installations from source made manually by the admin of the system. Some package managers (Homebrew, I'm looking specifically at you) have abused that path to install their things, but 1) it's not our fault that someone else incorrectly abuses that path (and they seem to be fixing it for newer archs; e.g., they started using /opt/homebrew for Apple Silicon), 2) there's no better path than /usr/local, 3) we still allow changing it for systems where this might not be the desired path (MacOS Intel with hombrew), and 4) it's _the standard_. See a related conversation with Ingo (OpenBSD maintainer): On 7/27/22 16:16, Ingo Schwarze wrote: > Hi Alejandro, [...] > > Alejandro Colomar wrote on Sun, Jul 24, 2022 at 07:07:18PM +0200: >> On 7/24/22 16:57, Ingo Schwarze wrote: >>> Alejandro Colomar wrote on Sun, Jul 24, 2022 at 01:20:46PM +0200: > >>>> /usr/local is for sysadmins to build from source; > >>> Doing that is *very* strongly discouraged on OpenBSD. > >> I guess that's why the directory was reused in the BSDs to install ports >> (probably ports were installed by the sysadmin there, and by extension, >> ports are now always installed there, but that's just a guess). > > Maybe. In any case, the practice of using /usr/local for packages > created from ports is significantly older than the recommendation > to refrain from using upstream "make install" outside the ports > framework. > > * The FreeBSD ports framework was started by Jordan Hubbard in 1993. > * The ports framework was ported from FreeBSD to OpenBSD > by Niklas Hallqvist in 1996. > * NetBSD pkgsrc was forked from FreeBSD ports by Alistair G. Crooks > and Hubert Feyrer in 1997. > > I failed to quickly find Jordan's original version, but rev. 1.1 > of /usr/ports/infrastructure/mk/bsd.port.mk in OpenBSD (dated Jun 3 > 22:47:10 1996 UTC) already said > > LOCALBASE ?= /usr/local > PREFIX ?= ${LOCALBASE} > [...] >> I had a discussion in NGINX Unit about it, and >> the decission for now has been: "support prefix=/usr/local for default >> manual installation through the Makefile, and let BSD users adjust to >> their preferred path". > > That's an *excellent* solution for the task, thanks for doing it > the right way. By setting PREFIX=/usr/local by default in the > upstream Makefile, you are minimizing the work for *BSD porters. > > The BSD ports frameworks will typically run the upstreak "make install" > with the variable DESTDIR set to a custom value, for example > > DESTDIR=/usr/ports/pobj/groff-1.23.0/fake-amd64 > > so if the upstream Makefile sets PREFIX=/usr/local , > that's perfect, everything gets installed to the right place > without an intervention by the person doing the porting. > > Of course, if the upstream Makefile would use some other PREFIX, > that would not be a huge obstacle. All we have to do in that case > is pass the option --prefix=/usr/local to the ./configure script, > or something equivalent if the software isn't using GNU configure. > >> We were concerned that we might get collisions >> with the BSD port also installing in /usr/local, but that's the least >> evil (and considering BSD users don't typically run `make install`, it's >> not so bad). > > It's not bad at all. It's perfect. > > Of course, if a user wants to install *without* the ports framework, > they have to provide their own --prefix. But that's not an issue > because it is easy to do, and installing without a port is discouraged > anyway. === Directory variables should never contain a trailing slash (I've learned that the hard way, where some things would break unexpectedly). Especially, make(1) is likely to have problems when things have double slashes or a trailing slash, since it treats filenames as text strings. I've removed the trailing slash from the prefix, and added it to the derivate variables just after the prefix. pkg-config(1) also expects directory variables to have no trailing slash. === I also removed the code that would set variables as depending on the prefix if they didn't start with a slash, because that is a rather non-obvious behavior, and things should not always depend on prefix, but other dirs such as $(runstatedir), so if we keep a similar behavior it would be very unreliable. Better keep variables intact if set, or use the default if unset. === Print the real defaults for ./configure --help, rather than the actual values. === I used a subdirectory under the standard /var/lib for NXT_STATE, instead of a homemade "state" dir that does the same thing. === Modified the Makefile to create some dirs that weren't being created, and also remove those that weren't being removed in uninstall, probably because someone forgot to add them. === Add new options for setting the new variables, and rename some to be consistent with the standard names. Keep the old ones at configuration time for compatibility, but mark them as deprecated. Don't keep the old ones at exec time. === A summary of the default config is: Unit configuration summary: bin directory: ............. "/usr/local/bin" sbin directory: ............ "/usr/local/sbin" lib directory: ............. "/usr/local/lib" include directory: ......... "/usr/local/include" man pages directory: ....... "/usr/local/share/man" modules directory: ......... "/usr/local/lib/unit/modules" state directory: ........... "/usr/local/var/lib/unit" tmp directory: ............. "/tmp" pid file: .................. "/usr/local/var/run/unit/unit.pid" log file: .................. "/usr/local/var/log/unit/unit.log" control API socket: ........ "unix:/usr/local/var/run/unit/control.unit.sock" Link: <https://www.gnu.org/prep/standards/html_node/Directory-Variables.html> Link: <https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html> Reviewed-by: Artem Konev <a.konev@f5.com> Reviewed-by: Andrew Clayton <a.clayton@nginx.com> Tested-by: Andrew Clayton <a.clayton@nginx.com> Reviewed-by: Konstantin Pavlov <thresh@nginx.com> Signed-off-by: Alejandro Colomar <alx@nginx.com>
2023-01-12Autodetect endianness.Andrew Clayton1-0/+31
In configure we set NXT_HAVE_LITTLE_ENDIAN for i386, amd64 and x86_64. However that misses at least AArch64 (arm64) where it's usually run in little endian mode. However none of that really matters as NXT_HAVE_LITTLE_ENDIAN isn't used anywhere. So why this patch? The only place we need to explicitly know about endianness is the nxt_websocket_header_t structure where we lay it out differently depending on endianness. This is currently done using BYTE_ORDER, LITTLE_ENDIAN and BIG_ENDIAN macros. However on at least illumos (OpenSolaris / OpenIndiana) those macros are not defined and we get compiler errors due to duplicate structure members. So let's use our own NXT_HAVE_{BIG,LITTLE}_ENDIAN macros. However it would be better to detect endianness programmatically as some architectures can run in either mode, e.g Linux used to run in big endian on PowerPC but has since switched to little endian (to match x86). This commit adds an auto/endian script (using a slightly modified version of the test program from nginx's auto script), that checks for the endianness of the platform being built on. E.g checking for endianness ... little endian The next commit will switch the nxt_websocket_header_t structure over to these new macros. Link: <https://github.com/nginx/unit/pull/298> Link: <https://developer.ibm.com/articles/l-power-little-endian-faq-trs/> Tested-by: Alejandro Colomar <alx@nginx.com> Reviewed-by: Alejandro Colomar <alx@nginx.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2022-12-14Java: upgrading third-party components.Sergey A. Osokin2-16/+16