PR-URL: https://github.com/nodejs/node/pull/49639
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
This patch:
- Initializes cppgc in InitializeOncePerProcess() when
kNoInitializeCppgc is not set
- Create a CppHeap and attach it to the Isolate when
there isn't one already during IsolateData initialization.
The CppHeap is detached and terminated when IsolateData
is freed.
- Publishes the cppgc headers in the tarball.
This allows C++ addons to start using cppgc to manage objects.
A helper node::SetCppgcReference() is also added to help addons
enable cppgc tracing in a user-defined object.
Co-authored-by: Joyee Cheung <joyeec9h3@gmail.com>
Refs: https://github.com/nodejs/node/issues/40786
PR-URL: https://github.com/nodejs/node/pull/45704
Refs: https://docs.google.com/document/d/1ny2Qz_EsUnXGKJRGxoA-FXIE2xpLgaMAN6jD7eAkqFQ/edit
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.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>
This will allow distribution packages to select an alternative
location for the unofficial libnode.so. For example, on Fedora it
will install into /usr/lib64 on 64-bit systems.
Signed-off-by: Stephen Gallagher <sgallagh@redhat.com>
PR-URL: https://github.com/nodejs/node/pull/44361
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
The shared libraries will now be stores in lib.target as opposed to
obj.target, libnode.version.so, libnode.x (for npm backwards compat and
testing), and libnode.version.x (for builds). The install will also
include libnode.so link that points to libnode.version.so (this will be
used by native npms for backwards compat).
PR-URL: https://github.com/nodejs/node/pull/42256
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Co-authored-by: Gaby Baghdadi <baghdadi@ca.ibm.com>
Co-authored-by: Wayne Zhang <shuowang.zhang@ibm.com>
There are no clear indicators anyone is using the dtrace USDT probes.
ETW support is very intertwined with the dtrace infrastructure. It's not
clear if anyone uses ETW so to keep things simple it too is removed.
Fixes: https://github.com/nodejs/node/issues/43649
PR-URL: https://github.com/nodejs/node/pull/43652
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
There are no indicators that anyone is actually using this. Quite the
opposite: it was broken more than it was working during its lifetime.
PR-URL: https://github.com/nodejs/node/pull/43651
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
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>
PR-URL: https://github.com/nodejs/node/pull/41610
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
zoslib is a C/C++ runtime library and an extended implementation
of the z/OS LE C Runtime Library.
PR-URL: https://github.com/nodejs/node/pull/41493
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Co-authored-by: Gaby Baghdadi <baghdadi@ca.ibm.com>
PR-URL: https://github.com/nodejs/node/pull/41060
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
v8.h was split into a multitude of smaller headers.
Refs: https://github.com/nodejs/node/issues/39876
PR-URL: https://github.com/nodejs/node/pull/40423
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Beth Griggs <bgriggs@redhat.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Because Node.js currently distributes all V8 headers, it is not clear
which ones are part of our API and ABI compatibility contract. V8 may
add, remove, or change headers at any time, preventing us sometimes
from updating because the change could affect addons which may depend
on them. Moreover, the `cppgc` library, included in V8, is exposed
even though it is still in active development and doesn't have a
stable API.
Node.js should choose exactly which headers are exposed and part of
our native API, so that it's easier to reason about changes during V8
updates and to prevent us from automatically increasing the API
surface when new headers are added by V8.
Instead of specifically excluding v8-inspector, only include `v8.h`,
`v8-platform.h` (used in `node.h`) and `v8-profiler.h`.
PR-URL: https://github.com/nodejs/node/pull/37570
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Shelley Vohr <codebytere@gmail.com>
Reviewed-By: Mary Marchini <oss@mmarchini.me>
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
This patch replaces usage of `filter` in such a way that it will be
compatible with Python 3. Also, this patch replaces the usage of `map`
to do a side-effect work with normal `for` loop.
PR-URL: https://github.com/nodejs/node/pull/25583
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
These headers are exposed from V8 for embedder and should not be
used by native addons.
Fixes https://github.com/nodejs/node/issues/22415
PR-URL: https://github.com/nodejs/node/pull/22586
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
After upgrading OpenSSL-1.1.0, header files depends on architectures
were changed. This fixes to copy all `deps/openssl/config/*.h' into
the install directory.
Fixes: https://github.com/nodejs/node/issues/4270
PR-URL: https://github.com/nodejs/node/pull/19794
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rod Vagg <rod@vagg.org>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
The npm install rules had a hidden dependency on the `node` binary
install rule creating the `$PREFIX/bin` directory.
Because with `./configure --shared` no binary is created, the rule
subsequently failed. Fix that by creating the directory before
creating the symlinks to the npm and npx scripts.
(Whether it makes sense to install npm without a `node` binary is
a separate question. This commit is not taking positions. :-))
Regression introduced in commit ed8c89a ("build: fix shared installing
target") which, as the commit log indicates, was itself a bug fix for
the `./configure --shared` install.
PR-URL: https://github.com/nodejs/node/pull/16438
Fixes: https://github.com/nodejs/node/issues/16437
Ref: https://github.com/nodejs/node/pull/15148
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Daijiro Wachi <daijiro.wachi@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
This commit adds lldbinit files from upstream V8 and also adds these so
that they get installed when `make install` is run.
Original commit message:
[tools] add lldbinit
The goal of this commit is to add the equivalent to gdbinit but
for lldb. I've tried to replicate the commands as close as possible
but I'm unsure about the jss command and hoping to get some feedback
on it in addition to the bta command which I'm not sure how/when
this could be used. This is probably just inexperience on my part.
The lldbinit file can be placed into a directory prefixed with dot
(.lldbinit) and the python script is currently expected to be in the
same directory. The path to the script can be changed manually if
needed as well.
NOTRY=true
Review-Url: https://codereview.chromium.org/2758373002
Cr-Commit-Position: refs/heads/master@{#44136}
PR-URL: https://github.com/nodejs/node/pull/12061
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Add support for abi stable module API (N-API) as "Experimental feature".
The goal of this API is to provide a stable Node API for native
module developers. N-API aims to provide ABI compatibility guarantees
across different Node versions and also across different
Node VMs - allowing N-API enabled native modules to just work
across different versions and flavors of Node.js without recompilation.
A more detailed introduction is provided in:
https://github.com/nodejs/node-eps/blob/master/005-ABI-Stable-Module-API.md
and https://github.com/nodejs/abi-stable-node/blob/doc/VM%20Summit.pdf.
The feature, during its experimental state, will be guarded by a runtime
flag "--napi-modules". Only when this flag is added to the command line
will N-API modules along with regular non N-API modules be supported.
The API is defined by the methods in "src/node_api.h" and
"src/node_api_types.h". This is the best
starting point to review the API surface. More documentation will follow.
In addition to the implementation of the API using V8, which is included
in this PR, the API has also been validated against chakracore and that
port is available in
https://github.com/nodejs/abi-stable-node/tree/api-prototype-chakracore-8.x.
The current plan is to provide N-API support in versions 8.X and 6.X
directly. For older versions, such as 4.X or pre N-API versions of 6.X,
we plan to create an external npm module to provide a migration path
that will allow modules targeting older Node.js versions to use the API,
albeit without getting the advantage of not having to recompile.
In addition, we also plan an external npm package with C++ sugar to
simplify the use of the API. The sugar will be in-line only and will
only use the exported N-API methods but is not part of the N-API
itself. The current version is in:
https://github.com/nodejs/node-api.
This PR is a result of work in the abi-stable-node repo:
https://github.com/nodejs/abi-stable-node/tree/doc,
with this PR being the cumulative work on the api-prototype-8.x
branch with the following contributors in alphabetical order:
Author: Arunesh Chandra <arunesh.chandra@microsoft.com>
Author: Gabriel Schulhof <gabriel.schulhof@intel.com>
Author: Hitesh Kanwathirtha <hiteshk@microsoft.com>
Author: Ian Halliday <ianhall@microsoft.com>
Author: Jason Ginchereau <jasongin@microsoft.com>
Author: Michael Dawson <michael_dawson@ca.ibm.com>
Author: Sampson Gao <sampsong@ca.ibm.com>
Author: Taylor Woll <taylor.woll@microsoft.com>
PR-URL: https://github.com/nodejs/node/pull/11975
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
The bundled c-ares isn't very suitable for consumption by addons,
isn't kept stable, and isn't exported on windows.
PR-URL: https://github.com/nodejs/node/pull/10283
Refs: https://github.com/nodejs/node-gyp/pull/1055
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
When configuring --without-ssl and then running make install
openssl headers will be copied from deps/openssl to the target
installation directory.
This commit adds a check for is node_use_openssl is set in which
case the headers are not copied.
PR-URL: https://github.com/nodejs/node/pull/11766
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Brian White <mscdex@mscdex.net>
The build system currently creates a shared library on OS X with the
same name as on Linux i.e. libnode.so.48. This is inconsistent with
the conventions on OS X which uses libnode.48.so This commit changes
the build process and install.py (used by make binary) to build with
the correct name on OS X when the --shared configure parameter is used.
PR-URL: https://github.com/nodejs/node/pull/7687
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Add configure flag for building a shared library that can be
embedded in other applications (like Electron). Add flags
--without-bundled-v8 and --without-v8-platform to control V8
dependencies used.
PR-URL: https://github.com/nodejs/node/pull/6994
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Fedor Indutny <fedor@indutny.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
As the name suggests, it's for internal use only, so don't install it.
Including it in an add-on doesn't work because the file depends on other
header files that are not installed.
Adding it to the install list appears to have been an oversight in
commit 32478acf ("build: unix install node and dep library headers").
PR-URL: https://github.com/nodejs/node/pull/6913
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Johan Bergström <bugs@bergstroem.nu>
Reviewed-By: Robert Jefe Lindstaedt <robert.lindstaedt@gmail.com>
As Node.js expects either Python 2.6 or 2.7 installed to work properly,
simplejson module is no longer necessary. It was included in Python 2.6
as the json module.
PR-URL: https://github.com/nodejs/node/pull/6101
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Johan Bergström <bugs@bergstroem.nu>
Rewriting npm shebang in install.py violates user expectations
among other things.
The shebang in npm.js is kept as #!/usr/bin/env node.
Fixes: https://github.com/nodejs/node/issues/6095
PR-URL: https://github.com/nodejs/node/pull/6098
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Johan Bergström <bugs@bergstroem.nu>
As of cc192f0e we've now in sync with upstream which means that we
also can allow our users to build against a shared version of c-ares.
Note: It is still up to users to make sure that the library version
is on par with what Node.js bundles.
This "reverts" commit 25fa5c4.
PR-URL: https://github.com/nodejs/node/pull/5775
Reviewed-By: Fedor Indutny <fedor@indutny.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
This change cleans up outstanding comments on #3032. It improves error
handling when no isolate file is provided and adds the --prof-process
flag to the node binary which executes the tick processor on the
provided isolate file.
PR-URL: https://github.com/nodejs/node/pull/4021
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Evan Lucas <evanlucas@me.com>
The tick processor is used to provide readable profiling information
from isolate tick logs (produced by a call to node -prof).
This patch installs the file at $PREFIX/share/doc/node/tick-processor.
PR-URL: https://github.com/nodejs/node/pull/3032
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
This PR is the first step enabling support for native modules
for AIX. The main issue is that unlike linux where all
symbols within the Node executable are available to the shared
library for a native module (npm), on AIX the symbols must
be explicitly exported. In addition, when the shared library is
built it must be linked using a list of the available symbols.
This patch covers the changes need to:
1) Export the symbols when building the node executable
2) Generate the file listing the symbols that can be used when
building the shared library.
For AIX, it breaks the build process into 2 steps. The first builds
a static library and then generates a node.exp file which contains
the symbols from that library. The second builds the node executable
and uses the node.exp file to specify which symbols should be
exported. In addition, it save the node.exp file so that it can
later be used in the creation of the shared library when building
a native module.
The following additional steps will be required in dependent projects
to fully enable AIX for native modules and are being worked
separately:
- Updates to node-gyp to use node.exp when creating the
shared library for a native module
- Fixes to gyp related to copying files as covered in
https://codereview.chromium.org/1368133002/patch/1/10001
- Pulling in updated gyp versions to Node and node-gyp
- Pulling latest libuv
These changes were done to minimize the change to other platforms
by working within the existing structure to add the 2 step process
for AIX without changing the process for other platforms.
PR-URL: https://github.com/nodejs/node/pull/3114
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
This commit replaces instances of io.js with Node.js, based on the
recent convergence. There are some remaining instances of io.js,
related to build and the installer.
Fixes: https://github.com/nodejs/node/issues/2361
PR-URL: https://github.com/nodejs/node/pull/2367
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: João Reis <reis@janeasystems.com>
Upgrade the bundled V8 and update code in src/ and lib/ to the new API.
Notable backwards incompatible changes are the removal of the smalloc
module and dropped support for CESU-8 decoding. CESU-8 support can be
brought back if necessary by doing UTF-8 decoding ourselves.
This commit includes https://codereview.chromium.org/1192973004 to fix
a build error on python 2.6 systems. The original commit log follows:
Use optparse in js2c.py for python compatibility
Without this change, V8 won't build on RHEL/CentOS 6 because the
distro python is too old to know about the argparse module.
PR-URL: https://github.com/nodejs/io.js/pull/2022
Reviewed-By: Rod Vagg <rod@vagg.org>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
