Where to find "node.lib" for all operating systems and archs?

[Danielku15]

Hey everyone.

TL;DR: From which source can I obtain MacOS "libnode.dylib" for different architectures for manual compiling and linking of Node addons?

Long Version:

I am currently working on a special Skia wrapper for my project for which I target a matrix of runtimes (Node, .net, Java), operating systems (Windows, Linux, Android, MacOS, iOS) and architectures (x64, x86, arm, arm64). I am compiling all my native libs with GN/Ninja and Clang using the general skia toolchain and would also like to do so for my Node Addons.

As I have already quite an advanced build system in place handling all other targets, I would like to avoid introducing node-gyp and trying to get it compile in the way I want.

I know the headers are available via many sources like:

• https://github.com/nodejs/node-api-headers
• https://nodejs.org/download/release/v18.18.0/node-v18.18.0-headers.tar.gz
• apt-get

But how about node libraries required for linking?

• For Windows there are subfolders in https://nodejs.org/download/release/latest/ or https://nodejs.org/dist/latest/ containing the lib.
• For Linux (e.g. Ubuntu) I can install the libnode-dev packages for the desired architecture.
• But how about MacOS? Where can I obtain the libnode.dylib for the different cpu architectures?

I couldn't find yet anything about the libs in the docs or the node-gyp source code that would help me.

[bnoordhuis]

I think you're conflating two things.

• building an add-on; needs node-gyp, anything else means you're on your own and godspeed (edit: take a look at cmake-js)

• building node as a shared library; not to be confused with node.lib which is just an export of node's API for add-on consumption

[Danielku15]

building an add-on; needs node-gyp, anything else means you're on your own and godspeed (edit: take a look at cmake-js)

I can confirm that this point is my goal. node-gyp is not in my interest to use due to various reasons I can share if anyone is interested. The main reason is: I have already a fully working setup for cross compiling 16 static libs (skia) and 29 shared libs (my wrapper) targeting 2 other runtimes (.net & java) and don't want to reinvent the wheel for Node only with (especially considering nodejs/node-gyp#2295). 😫

The statement that node-gyp is mandatory is not fully true, this toolchain also just calls other compilers with the right inputs. It definitely makes things easier if you are creating only a node addon but in my case its different. Yes are things which don't come for free anymore by not using node-gyp but I am willing to invest those efforts.

I digged a bit deeper into the compile flags used when building with node-gyp and got things compiling and linking. Here my findings in the hope some future readers might find them useful:

• On Windows you need the node.lib to link against the exports of the node .exe (not any dll). This way when the node.exe will load the addon, the "node.exe" required by the addon is already loaded and the symbols are available through the main process. I haven't seen until now that a windows executable exporting symbols which are imported by a DLL and then the executable loads the DLL during runtime. Hence my initial confusion.
• On Linux it is allowed to have unresolved external symbols in shared objects unless the linker is instructed to check those and fail. e.g. via --no-undefined. Hence no lib or other input is needed.
• On MacOS the following flag trigger a similar behavior like on Linux. The napi symbols are allowed to stay unresolved during linking and are then provided by the host executable during runtime. -undefined dynamic_lookup

I haven't tested yet if things are fully working during runtime but the libs are already compiling and linking for my whole matrix. Soon I will be able to target 3 runtimes via 38 shared libs in my project 🥳

Update: First tests on Windows work fine. No node-gyp involved.

[bnoordhuis]

The statement that node-gyp is mandatory is not fully true, this toolchain also just calls other compilers with the right inputs.

Yes, obviously. The point is you're off the supported path, hence godspeed.

n-api + the well-known napi_register_module_v1 symbol is arguably your best way forward because that at least comes with a promise of stability.