| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Module is called 'skel'. Configure with
$ ./configure skel
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
[ Tweaked subject - Andrew ]
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
[ Tweaked subject - Andrew ]
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>
|
|
[ 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>
|
|
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>
|
|
-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.
|
|
Acked-by: Timo Stark <t.stark@nginx.com>
[ Remove trailing '.' from subject line - Andrew ]
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
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>
|
|
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>
|
|
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 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>
|
|
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>
|
|
|
|
This fixes an issue addressed in 651f5a37f5b8 on FreeBSD 12.
The problem manifested itself as:
configuring Ruby module
checking for -fdeclspec ... found
checking for Ruby library ... not found
checking for Ruby library in /usr/local/lib ... not found
./configure: error: no Ruby found.
|
|
Future releases of GCC are planning to remove[0] default support for
some old features that were removed from C99 but GCC still accepts.
We can test for these changes by using the following -Werror=
directives
-Werror=implicit-int
-Werror=implicit-function-declaration
-Werror=int-conversion
-Werror=strict-prototypes
-Werror=old-style-definition
Doing so revealed an issue with the auto/ tests in that the test
programs always define main as
int main()
rather than
int main(void)
which results in a bunch of errors like
build/autotest.c:3:23: error: function declaration isn't a prototype [-Werror=strict-prototypes]
3 | int main() {
| ^~~~
build/autotest.c: In function 'main':
build/autotest.c:3:23: error: old-style function definition [-Werror=old-style-definition]
The fix was easy, it only required fixing the main prototype with
find -type f -exec sed -i 's/int main() {/int main(void) {/g' {} \;
Regardless of these upcoming GCC changes, this is probably a good thing
to do anyway for correctness.
[0]: https://fedoraproject.org/wiki/Changes/PortingToModernC
Link: <https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CJXKTLXJUPZ4F2C2VQOTNMEA5JAUPMBD/>
Link: <https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6SGHPHPAXKCVJ6PUZ57WVDQ5TDBVIRMF/>
Reviewed-by: Alejandro Colomar <alx@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
PHP 8.2 changed the prototype of the function, removing the last
parameter.
Signed-off-by: Remi Collet <remi@remirepo.net>
Cc: Timo Stark <t.stark@nginx.com>
Cc: George Peter Banyard <girgias@php.net>
Tested-by: Andy Postnikov <apostnikov@gmail.com>
Acked-by: Andy Postnikov <apostnikov@gmail.com>
Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
Signed-off-by: Alejandro Colomar <alx@nginx.com>
|
|
Add -fdeclspec to NXT_RUBY_CFLAGS for Clang, if it's available.
Clang incorrectly reports 1 for __has_declspec_attribute(x) in
some cases, such as MacOS or Cygwin. That causes ruby code to
break. ruby added -fdeclspec to their CFLAGS in 2019 to
workaround this bug, since it enables __declspec() and therefore,
the compiler behavior matches what it reports.
Since we don't know what are all the architectures that trigger
the clang bug, let's add the flag for all of them (especially
since it should be harmless).
Add this workaround only at the time of configuring the ruby
module. This way we don't clutter the global NXT_CFLAGS with an
unnecessary flag.
Link: unit bug <https://github.com/nginx/unit/issues/653>
Link: ruby bug <https://bugs.ruby-lang.org/issues/18616>
Link: LLVM bug <https://github.com/llvm/llvm-project/issues/49958>
Commit: LLVM: Add -fdeclspec <d170c4b57a91adc74ca89c6d4af616a00323b12c>
Commit: ruby: Use -fdeclspec <0958e19ffb047781fe1506760c7cbd8d7fe74e57>
|
|
|
|
|
|
|
|
The patch removes the "files" section from package.json to avoid future issues
with missing files. For package testing purposes, 'npm pack' is used instead
of plain 'tar' to simulate packaging more accurately.
|
|
In Go 1.16, the module-aware mode is enabled by default; to fall back to
previous behavior, the GO111MODULE environment variable should be set to
'auto'.
Details: https://golang.org/doc/go1.16
|
|
This makes the "sed" instruction simpler and more portable, as the previous
variant didn't work well on BSD systems due to the "\s" metacharacter.
Thanks to Sergey A. Osokin <osa@FreeBSD.org.ru> for spotting this issue.
Also, this should prevent accidentally creating a version 1.0.0 package.
|
|
Globally installed modules require a globally installed libunit.
The "binding_pub.gyp" file is the correct version, otherwise linked module
may have unresolved symbols because libunit is not linked.
|
|
|
|
Thanks to @wujjpp.
This closes #490 PR on GitHub.
|
|
|
|
|
|
This variant will be more interoperable across various systems
and it's already used in Ruby module.
Otherwise, configure tests fail on NetBSD with:
gcc: Missing argument for -Wl,-rpath
|
|
This closes #461 issue on GitHub.
|
|
|
|
This is required for futher ASGI implementation.
|
|
No functional changes. Get ready for an increase in file number.
|
