[node] node-gyp dependent packages may not work correctly due to node-lts ld.so.cache

  • Open
  • quality assurance status badge
Details
One participant
  • Abhishek Cherath
Owner
unassigned
Submitted by
Abhishek Cherath
Severity
normal
A
A
Abhishek Cherath wrote on 20 Nov 2022 01:06
(address . bug-guix@gnu.org)
381e762e-5a44-a746-b3c9-1a680d7ec260@quic.us
Hello,

This is a fairly involved bug report, the basic idea is that several npm
packages depend on [node-gyp](https://www.npmjs.com/package/node-gyp),
which is a build tool (written in python) that compiles native plugins
for nodejs (so generally C/C++ code).

This tool uses the *system* C/C++ compiler, so on a guix system with
gcc-toolchain, that would be gcc-12. this allows for the compilation and
installation of these packages in node_modules fine. However, at runtime
(which happens as `node program.js`) since the dynamic linker looks in
the node-lts package's ld.so.cache, it tries to link against gcc-10's
libstdc++.so.6, and errors out because of missing symbols.

To Reproduce, attempt the following (this isn't a particularly minimal
example)
1. guix shell --pure gcc-toolchain libuv mesa make python2 pkg-config
libx11 libxext libxi node
2. cd <<SOME-DIR>>
3. CC=gcc npm i gl
4. guix shell gcc-toolchain libuv mesa make python2 pkg-config libx11
libxext libxi node
5. echo "var gl = require('gl')(64, 64, { preserveDrawingBuffer: true
})" > test.js
6. node test.js

observe "ERR_DLOPEN_FAILED", with Error:
/gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/libstdc++.so.6:
version `GLIBCXX_3.4.29' not found

running with LD_DEBUG=all, shows that node-14.19.3's linked gcc's
libstdc++ is used:

3608: find library=libstdc++.so.6 [0]; searching
3608: search
cache=/gnu/store/mgxvqphymkf1xfz4zryppr1jwnd5xcyw-node-14.19.3/etc/ld.so.cache
3608: trying
file=/gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/libstdc++.so.6


I'm not really certain how one would go about solving this tbh, I'm
planning to look a little deeper into how node-gyp decides what C++
compiler to use, might be a matter of setting some env vars or
something? any ideas are appreciated.

Thank you,
Abhishek.
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 59393@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 59393
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch