Most changes are gated by the `clang==1` condition to avoid breaking
MSVC builds.
Select C/C++ language standard with ClCompile options.
This avoids passing the `-std:c++20` flag while compiling C code.
Do it only under clang option to avoid breaking addons until node-gyp
supports the new LanguageStandard options.
Disable precompiled header configuration for now as it doesn't seem to
work with clang-cl.
Disable C++20 warnings emitted by the Visual Studio C++ STL.
They're very noisy and not our responsibility to fix.
Co-authored-by: Daniel Lemire <daniel@lemire.me>
Co-authored-by: Stefan Stojanovic <stefan.stojanovic@janeasystems.com>
PR-URL: https://github.com/nodejs/node/pull/52870
Reviewed-By: Daniel Lemire <daniel@lemire.me>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Fixes: https://github.com/nodejs/node/issues/35339
Co-authored-by: Pooja D P <Pooja.D.P@ibm.com>
Co-authored-by: Teutates <103068388+Teutates@users.noreply.github.com>
Co-authored-by: Antoine du Hamel <duhamelantoine1995@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/43987
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
V8 and Node.js had defined `NOMINMAX` on Windows for a long time. In
recent changes, V8 added `std::numeric_limits::min` usages in its
header files which caused addons without `NOMINMAX` defines failed
to compile.
Define `NOMINMAX` in common.gypi so that addons can be compiled with
the latest V8 header files.
PR-URL: https://github.com/nodejs/node/pull/52794
Fixes: https://github.com/nodejs/nan/issues/968
Refs: https://github.com/nodejs/gyp-next/pull/244
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Python 3.9 on IBM i now properly returns "os400" for sys.platform
instead of claiming to be AIX as it did previously. While the IBM i PASE
environment is compatible with AIX, it is a subset and has numerous
differences which makes it beneficial to distinguish, however this means
that it now needs explicit support here.
PR-URL: https://github.com/nodejs/node/pull/46739
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
PR-URL: https://github.com/nodejs/node/pull/46194
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
daae938f32 broke addons which create their own `Isolate`
instances, because enabling the shared-readonly-heap feature
of V8 requires all snapshots used for different `Isolate`s to
be identical. Usage of addons that do this has probably
decreased quite a bit since Worker threads were introduced
in Node.js, but it’s still a valid use case, and in any case
the breakage was probably not intentional (although the referenced
commit did require test changes because of this issue).
This commit addresses this issue partially by caching the
V8 snapshot parameters and ignoring ones passed in from users
in `NewIsolate()` when this feature is enabled, and makes
the `NodeMainInstance` snapshot-based isolate creation
also re-use this code.
PR-URL: https://github.com/nodejs/node/pull/45885
Reviewed-By: James M Snell <jasnell@gmail.com>
Node.js unofficially supports a shared library variant where the
main node executable is a thin wrapper around node.dll/libnode.so.
The key benefit of this is to support embedding Node.js in other
applications.
Since Node.js 12 there have been a number of issues preventing the
shared library build from working correctly, primarily on Windows:
* A number of functions used executables such as `mksnapshot` are
not exported from `libnode.dll` using a `NODE_EXTERN` attribute
* A dependency on the `Winmm` system library is missing
* Incorrect defines on executable targets leads to `node.exe`
claiming to export a number of functions that are actually in
`libnode.dll`
* Because `node.exe` attempts to export symbols, `node.lib` gets
generated causing native extensions to try to link against
`node.exe` not `libnode.dll`.
* Similarly, because `node.dll` was renamed to `libnode.dll`,
native extensions don't know to look for `libnode.lib` rather
than `node.lib`.
* On macOS an RPATH is added to find `libnode.dylib` relative to
`node` in the same folder. This works fine from the
`out/Release` folder but not from an installed prefix, where
`node` will be in `bin/` and `libnode.dylib` will be in `lib/`.
* Similarly on Linux, no RPATH is added so LD_LIBRARY_PATH needs
setting correctly for `bin/node` to find `lib/libnode.so`.
For the `libnode.lib` vs `node.lib` issue there are two possible
options:
1. Ensure `node.lib` from `node.exe` does not get generated, and
instead copy `libnode.lib` to `node.lib`. This means addons
compiled when referencing the correct `node.lib` file will
correctly depend on `libnode.dll`. The down side is that
native addons compiled with stock Node.js will still try to
resolve symbols against node.exe rather than libnode.dll.
2. After building `libnode.dll`, dump the exports using `dumpbin`,
and process this to generate a `node.def` file to be linked into
`node.exe` with the `/DEF:node.def` flag. The export entries
in `node.def` will all read
```
my_symbol=libnode.my_symbol
```
so that `node.exe` will redirect all exported symbols back to
`libnode.dll`. This has the benefit that addons compiled with
stock Node.js will load correctly into `node.exe` from a shared
library build, but means that every embedding executable also
needs to perform this same trick.
I went with the first option as it is the cleaner of the two
solutions in my opinion. Projects wishing to generate a shared
library variant of Node.js can now, for example,
```
.\vcbuild dll package vs
```
to generate a full node installation including `libnode.dll`,
`Release\node.lib`, and all the necessary headers. Native addons
can then be built against the shared library build easily by
specifying the correct `nodedir` option.
For example
```
>npx node-gyp configure --nodedir
C:\Users\User\node\Release\node-v18.0.0-win-x64
...
>npx node-gyp build
...
>dumpbin /dependents build\Release\binding.node
Microsoft (R) COFF/PE Dumper Version 14.29.30136.0
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file build\Release\binding.node
File Type: DLL
Image has the following dependencies:
KERNEL32.dll
libnode.dll
VCRUNTIME140.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
...
```
PR-URL: https://github.com/nodejs/node/pull/41850
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Beth Griggs <bgriggs@redhat.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
This pull request updates the OpenSSL version that is statically
linked with Node.js from OpenSSl 1.1.1 to quictls OpenSSL 3.0.0+quic.
This pull request will replace the OpenSSL version that is currently
in the deps directory and when performing a normal build
OpenSSL 3.0+quic will be statically linked to the Node.js executable.
We will still be able to dynamically link to OpenSSL 1.1.1 and we have
a CI job which dynamically links to OpenSSL 1.1.1 which is run for
every pull request to make sure that we maintain backward compatibility.
PR-URL: https://github.com/nodejs/node/pull/38512
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
compability -> compatibility
PR-URL: https://github.com/nodejs/node/pull/39044
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Zijian Liu <lxxyxzj@gmail.com>
Currently there are a number of deprecation warnings generated when
linking with OpenSSL 3.0, for example:
In file included from ../src/crypto/crypto_scrypt.h:6,
from ../src/crypto/crypto_scrypt.cc:1:
../src/crypto/crypto_util.h:64:37: warning:
‘void RSA_free(RSA*)’ is deprecated: Since OpenSSL 3.0
[-Wdeprecated-declarations]
64 | using RSAPointer = DeleteFnPtr<RSA, RSA_free>;
The reason for this is that I had placed the macro OPENSSL_API_COMPAT
inside of the node_shared_openssl="false" clause, but that was a
mistake and this macro should have gone into the else clause instead.
PR-URL: https://github.com/nodejs/node/pull/38126
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reintroduces the ngtcp2 and nghttp3 dependencies, building those by
default if the vendored-in openssl (with QUIC support) is used or the
shared openssl defines `OPENSSL_INFO_QUIC`.
Upates the version metadata to reflect whether ngtcp2 and nghttp3 are
present.
ngtcp2 as of
2381f7f7b6
nghttp3 as of
66ad30f0a8
Signed-off-by: James M Snell <jasnell@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/37682
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
This commit enables node to dynamically link against OpenSSL 3.0.
The motivation for opening this PR even though OpenSSL 3.0 has not been
released yet is to allow a nightly CI job to be created. This will
allow us stay on top of changes required for OpenSSL 3.0, and also to
make sure that changes to node crypto do not cause issues when linking
to OpenSSL 3.0.
PR-URL: https://github.com/nodejs/node/pull/37669
Refs: https://github.com/nodejs/node/issues/29817
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
There is no reason to hide FIPS functionality behind build flags.
OpenSSL always provide the information about FIPS availability via
`FIPS_mode()` function.
This makes the user experience more consistent, because the OpenSSL
library is always queried and the `crypto.getFips()` always returns
OpenSSL settings.
Fixes#34903
PR-URL: https://github.com/nodejs/node/pull/36341
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Building Node.js with `--debug` takes a long time and generates
binaries that can be hard to work with due to their size, in
particular because debug builds of V8 are large.
Sometimes, it’s sufficient to build the Node.js parts with native
debugging options enabled. Add an option for that.
PR-URL: https://github.com/nodejs/node/pull/31644
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Rich Trott <rtrott@gmail.com>
`__executable_start` is provided by GNU's and LLVM's default linker
scripts, obviating the need to plug in a custom linker script.
The problem with our bespoke linker script is that it works with ld.bfd
but not ld.gold and cannot easily be ported because the latter linker
doesn't understand the `INSERT BEFORE` directive.
The /proc/self/maps scanner is updated to account for the fact that
there are a number of sections between `&__executable_start` and
the start of the .text section.
Fortunately, those sections are all mapped into the same memory segment
so we only need to look at the next line to find the start of our text
segment.
Fixes: https://github.com/nodejs/node/issues/31520
PR-URL: https://github.com/nodejs/node/pull/31547
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: David Carlier <devnexen@gmail.com>
Moves the option that instructs Node.js to-remap its static code to
large pages from a configure-time option to a runtime option. This
should make it easy to assess the performance impact of such a change
without having to custom-build.
PR-URL: https://github.com/nodejs/node/pull/30954
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Co-authored-by: David Carlier <devnexen@gmail.com>
When compiled with `--with-intl=small` and
`--with-icu-default-data-dir=PATH`, Node.js will use PATH as a
fallback location for the ICU data.
We will first perform an access check using fopen(PATH, 'r') to
ensure that the file is readable. If it is, we'll set the
icu_data_directory and proceed. There's a slight overhead for the
fopen() check, but it should be barely measurable.
This will be useful for Linux distribution packagers who want to
be able to ship a minimal node binary in a container image but
also be able to add on the full i18n support where needed. With
this patch, it becomes possible to ship the interpreter as
/usr/bin/node in one package for the distribution and to ship the
data files in another package (without a strict dependency
between the two). This means that users of the distribution will
not need to explicitly direct Node.js to locate the ICU data. It
also means that in environments where full internationalization is
not required, they do not need to carry the extra content (with
the associated storage costs).
Refs: https://github.com/nodejs/node/issues/3460
Signed-off-by: Stephen Gallagher <sgallagh@redhat.com>
PR-URL: https://github.com/nodejs/node/pull/30825
Reviewed-By: Steven R Loomis <srloomis@us.ibm.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Remove the legacy `http_parser` implementation as a dependency
and all code that uses it in favor of llhttp, given that the latter
has been the default for all of Node 12 with no outstanding issues.
PR-URL: https://github.com/nodejs/node/pull/29589
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Minwoo Jung <minwoo@nodesource.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
The custom linker script is compatible with GNU ld only.
As such, providin a new expliciting option to redirect to
a different one. lld seems unable to migrate this
large section w/o segfaulting so providing only the
base address anchor for now.
PR-URL: https://github.com/nodejs/node/pull/28938
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
It should be skipped if Node.js is built with the --without-snapshot
configure flag.
PR-URL: https://github.com/nodejs/node/pull/28467
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
* Add symlink from Release to out\Release for backward compat
PR-URL: https://github.com/nodejs/node/pull/27149
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Normalized boolean options in the gypfiles for consistency both
internally and with the V8 GN config.
Co-authored-by: Michaël Zasso <targos@protonmail.com>
PR-URL: https://github.com/nodejs/node/pull/26685
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
This commit introduces a new configuration flag named
--openssl-is-fips which is intended to be used when linking against
an OpenSSL library that is FIPS compatible.
The motivation for this is that Red Hat Enterprise Linux 8 (RHEL8)
comes with OpenSSL 1.1.1 and includes FIPS support, and we would
like to be able to dynamically link against this version and also have
FIPS features enabled in node, like would be done when statically
linking and using the --openssl-fips flag.
The suggestion here is to introduce a new flag:
$ ./configure --help
...
--openssl-is-fips specifies that the shared OpenSSL version is FIPS
compatible
This flag could be used in combination with the shared-openssl flag:
$ ./configure --shared-openssl ---openssl-is-fips
This will enable FIPS support in node and the runtime flags will be
availalbe to enable FIPS (--enable-fips, --force-fips).
PR-URL: https://github.com/nodejs/node/pull/25412
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
llhttp is modern, written in human-readable TypeScript, verifiable, and
is very easy to maintain.
See: https://github.com/indutny/llhttp
PR-URL: https://github.com/nodejs/node/pull/24059
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rod Vagg <rod@vagg.org>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
* Make inspector.gypi and v8_external_snapshot.gypi includible targets.
* Make `v8_dump_build_config` an action
* Better separate `js2c` and `natives_blob`
* process action outputs as sources
* trigger v8.gyp:postmortem-metadata from v8.gyp
PR-URL: https://github.com/nodejs/node/pull/23182
Refs: https://github.com/nodejs/node/pull/23156
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
