search

mapbox / node-pre-gyp

Node.js tool for easy binary deployment of C++ addons
BSD 3-Clause "New" or "Revised" License
1.11k stars 260 forks source link

{node_abi}-{platform}-{arch}.tar.gz filename format doesn't work with SunOS/Solaris/SmartOS/OmniOS #251

Open dekobon opened 7 years ago

dekobon commented 7 years ago

Due to an unfortunate history of the SunOS derivative operating systems. The uname -s (kernel name / platform name) returned on Solaris family operating systems all return sunos. The reality is that you would be hard-pressed to find a Solaris box to do a build on in order to create a binary that was compatible with Solaris 11 / OpenSolaris / SmartOS / Illumos / OmniOS, etc.

Would there be a way to add an additional field of information like distro or kernel version to allow binaries to be distinguished further? As it stands now, making downloadable binaries for the OpenSolaris derivative OSes is impossible to do an a way that is universally compatible.

In fact, this is a problem with Linux as well. Even though the Linux system call table remains fairly stable, there have been breaking changes from time to time and there is no guarantee that there will not be in the future, so capturing another metric to indicate the api compatibility level of the kernel would be a good idea.

To add some additional context about what I'm trying to accomplish practically - I want to save time by skipping the compilation step in a SmartOS 5.1 zone for the sqlite3 npm module. In Linux, the module uses node-pre-gyp's binary functionality to download a binary off of s3 and use it. However, I can't just create a binary and offer it to the project because the SmartOS (as with all SunOS derivatives) platform is identified by the string sunos - which means that the binary could be anything from actual SunOS to Solaris 11. Essentially, the platform identifier doesn't give any insight into the system call table compatibility across kernel versions (which is the same for Linux).

Mithgol commented 7 years ago

Do you have some exact idea of a better identifier in mind?

Mithgol commented 7 years ago

(I get it that package_name should allow something like {node_abi}-{platform}-{kernelid}-{arch}.tar.gz instead of a simpler {node_abi}-{platform}-{arch}.tar.gz, but what exactly would that {kernelid} be?)

Mithgol commented 7 years ago

Ideally, and in the future, if a good enough kernel identifier works well on the node-pre-gyp level, then it should be further proposed to Node.js developers as a new feature, a new field of Node's process object.

xzyfer commented 6 years ago

We (the node-sass team) ran into a similar issue trying to support Alpine. It reports itself as linux but doesn't always work with typical glibc binaries.

We ended up with {platform}_{platformvariant}-{arch}-{abiversion}_binding where platformvariant was musl on Alpine.

https://github.com/sass/node-sass/pull/1836

saper commented 6 years ago

We can have different libc ABIs (glibc2 vs musl), different stdc++ ABIs (clang vs GNU vs various versions of Visual Studio) and of course node ABI that includes V8. Additionally there are problems with bundled/unbundled OpenSSL and libuv, but that would be a real can of worms...