bug: Always first check `process.report.getReport`

[gabyx]

Why is this a bug.

• If we have no way to control the behavior of this library's fallback sequence etc, it might fail in envs, e.g. alpine linux (musl) with nix package manager which runs node (glibc, and pnpm also with glibc etc). This library then forcefully detects some /bin/ldd content which is from alpine (musl) which is a wrong result.

TL:DR:

• IMO the only reliable way to first check the process.report.getReport for anything (the context is node and checking for an executable ldd is highly orthogonal).

• Also making any fallback optional with env variable NODE_LOVELL_DETECT_LIBC_NO_FALLBACKS=true might be good.

Related:

nodejs/node#48204

I highly suggest to change that.

[lovell]

If you're using pnpm, did you see its supportedArchitectures feature?

This is designed for the situation where the install-time environment differs from the runtime environment, which is what you describe.

supportedArchitectures:
  os:
  - linux
  cpu:
  - x64
  libc:
  - glibc

Is there a specific package you're having problems with? Most native packages that offer prebuilt binaries for multiple platforms should support the supportedArchitectures approach (and if not, let's make that happen).

[gabyx]

Ah, ok , thanks for clarifying.

But still if one does not want to just install other architecture because
one is packaging up a package (Nix derivation) which
is specific for a certain architecture (os,cpu,libc), IMO its still wrong to look at the system /usr/bin/ldd and running commands at runtime.

I am even questioning, why the Node world has no way of hard baking these dependencies into the installed packages instead of doing a runtime lookup what to load. This is on the same level as dynamic library loading for binaries which is not understandable why this is done that way for the Node world which is all about which package manager you use 😆

Is there no node packaging system which downloads dependencies, configures them for the architecture(s) in question and then its baked, full stop, no messing around with runtime values, inspecting stuff.

However, the world is not like that: For this library isn't it still better to first look at platform.getReport because that belongs to the node executable which should be ground truth, and only then when enabled do other gimicks at startup, inspecting ldd or even running commands (⚠ !!!)

[gabyx]

As an more clear explanation:

We run pnpm install ... which (is built with Nix for x86_64,linux,glibc which correctly installs libraries for the platform.
Next we run vite build (vite is also installed with pnpm) which apparently loads some libs and their WASM which then just crashes, because they use
the logic of this library, which look at the OS (which is alpine with x86_64,linux,musl etc...)

[lovell]

The best solution to this problem would be that one that makes the use of this package redundant, namely Node.js itself providing details on the libc it is using. Until that point, this package exists, and we need to make it work for most people, most of the time, as quickly as possible and then get out of their way.

By selecting pnpm as your package manager you've already chosen well, so good work. I repeat my question from above: is there a specific package you're having problems with?

[gabyx]

namely Node.js itself providing details on the libc it is using:
thats what I mean, node.js -> platform.getReport() should be first priority, that is according to what you say, or I understand something wrong here.

1. Consider getRepor() first -> and return if the info is there
2. do other stuff (ldd)
3. system call... (I would not do that)

I am building a svelte app, which somehow includes it in the dependency chain, I need to check...

  lightningcss@1.29.2:
    dependencies:
      detect-libc: https://codeload.github.com/gabyx/detect-libc/tar.gz/635125ee3455eca71a232bc7c940ca01d420a495
    optionalDependencies:
      lightningcss-darwin-arm64: 1.29.2
      lightningcss-darwin-x64: 1.29.2
      lightningcss-freebsd-x64: 1.29.2
      lightningcss-linux-arm-gnueabihf: 1.29.2
      lightningcss-linux-arm64-gnu: 1.29.2
      lightningcss-linux-arm64-musl: 1.29.2
      lightningcss-linux-x64-gnu: 1.29.2
      lightningcss-linux-x64-musl: 1.29.2
      lightningcss-win32-arm64-msvc: 1.29.2
      lightningcss-win32-x64-msvc: 1.29.2

[lovell]

I've added a new libc detection method via commit 4d6eafe that checks the ELF header of the running Node.js executable, inspired partly by the implementation in Python's pip.

This should address the original problem, namely a glibc-linked Node.js running on a musl-based OS.