[Linux, x86_64] Deno crashes when using npm package (libstdc++.so.6: cannot open shared object file)

zakyum commented 2 months ago

Describe the bug

Deno 1.45.2 crashes saying that it can't find libstdc++.so.6 when trying to use it with the npm:duckdb package.

Think that this is primarily caused by using Deno with an npm library which uses a binary, the DuckDB binary to be precise. The DuckDB binary probably depends on libstdc++.so.6 and Deno can't find it because of Nix's isolating properties?

Works when installing Deno via their installer, i.e. without using Nix. Am not a Nix pro and don't know how to debug further, but would be willing to test more if provided instructions. Also I don't expect a fix, just wanted to mention this so that the problem is at least logged somewhere.

Steps To Reproduce

Steps to reproduce the behavior:

Get Deno via Nix

Crete nix-repro.ts file:


import { Database } from "npm:duckdb-async@1.0.0";

const db = await Database.create(":memory:");


3. Run file `deno run -A ./nix-repro.ts`
4. Get below error message
```console
$ deno run -A ./nix-repro.ts
error: Uncaught (in promise) TypeError: libstdc++.so.6: cannot open shared object file: No such file or directory
    at Object.Module._extensions..node (node:module:774:20)
    at Module.load (node:module:655:32)
    at Function.Module._load (node:module:523:12)
    at Module.require (node:module:674:19)
    at require (node:module:785:16)
    at Object.<anonymous> (file:///home/[project-name]/node_modules/.deno/duckdb@1.0.0/node_modules/duckdb/lib/duckdb-binding.js:4:15)
    at Object.<anonymous> (file:///home/[project-name]/node_modules/.deno/duckdb@1.0.0/node_modules/duckdb/lib/duckdb-binding.js:7:4)
    at Module._compile (node:module:730:34)
    at Object.Module._extensions..js (node:module:744:10)
    at Module.load (node:module:655:32)

Expected behavior

Should not crash. Works when installing Deno via their installer, i.e. without using Nix.

Additional context

Works on macOS.

 - system: `"aarch64-darwin"`
 - host os: `Darwin 23.4.0, macOS 14.4.1`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.20.5`
 - nixpkgs: `/Users/myuser/.nix-defexpr/channels/nixpkgs`

Notify maintainers

@06kellyjac

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

- system: `"x86_64-linux"`
 - host os: `Linux 6.5.0-41-generic, Ubuntu, 22.04.4 LTS (Jammy Jellyfish), nobuild`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.20.5`
 - nixpkgs: `/nix/store/qq257kq159smq2ais6i5halvssmc0g83-source`

Add a :+1: reaction to issues you find important.

eclairevoyant commented 2 months ago

Interestingly enough, I got a different error:

``` error: Uncaught (in promise) Error: Cannot find module '/tmp/tmp.6CdaLl095N/home/.cache/deno/npm/registry.npmjs.org/duckdb/1.0.0/lib/binding/duckdb.node' Require stack: - /tmp/tmp.6CdaLl095N/home/.cache/deno/npm/registry.npmjs.org/duckdb/1.0.0/lib/duckdb-binding.js - /tmp/tmp.6CdaLl095N/home/.cache/deno/npm/registry.npmjs.org/duckdb/1.0.0/lib/duckdb.js - /tmp/tmp.6CdaLl095N/home/.cache/deno/npm/registry.npmjs.org/duckdb-async/1.0.0/dist/duckdb-async.js - /tmp/tmp.6CdaLl095N/home/.cache/deno/npm/registry.npmjs.org/duckdb-async/1.0.0/dist/duckdb-async.js at Function.Module._resolveFilename (node:module:608:15) at Function.Module._load (node:module:486:27) at Module.require (node:module:674:19) at require (node:module:785:16) at Object. (file:///tmp/tmp.6CdaLl095N/home/.cache/deno/npm/registry.npmjs.org/duckdb/1.0.0/lib/duckdb-binding.js:4:15) at Object. (file:///tmp/tmp.6CdaLl095N/home/.cache/deno/npm/registry.npmjs.org/duckdb/1.0.0/lib/duckdb-binding.js:7:4) at Module._compile (node:module:730:34) at Object.Module._extensions..js (node:module:744:10) at Module.load (node:module:655:32) at Function.Module._load (node:module:523:12) ```

06kellyjac commented 2 months ago

Yes. On nixos there is no /usr/lib dynamic libraries to pick up, that's not specific to the deno package in nixpkgs.

Because that .node file is dynamically linked it wont work unless you either patch it or provide it the dynamic path it wants via an FHS env, nix-alien, or something similar.

The easiest test would just to throw steam-run in front of your command. That wraps around any command you give it and runs it in a more typical linux filestructure (FHS) so the program can find libs.

NixOS / nixpkgs