As the actual location of built libnode.so may differ depending on which
system was used to orchestrate the build (ninja or make),
multiple places should be searched for it's location.
PR-URL: https://github.com/nodejs/node/pull/58213
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.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>
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>
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>
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>
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>
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>
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 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>
Filip Skokan