0

One of my node_modules sub-dependencies needs GLIBCXX_3.4.29. The image that we use is based on Debian Buster, which doesnt have the needed version

Based on the answers from this, i tried to see what I got installed.

Below is the output of strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBCXX

GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
GLIBCXX_3.4.23
GLIBCXX_3.4.24
GLIBCXX_3.4.25
GLIBCXX_DEBUG_MESSAGE_LENGTH

I tried doing the solutions mentioned that involved apt installs and changing the export library.

I am not a C++ person, and I am not sure how to get the specific needed items from the tarball etc.

When I try to run the project locally, it works fine, since I have GLIBCXX_3.4.30 (and the missing .29) in my machine.

I also tried moving to node:16-bullseye and while that is better, it only gets up to GLIBCXX_3.4.28.

The node_module at "fault" is lru-native2 (source). In my case, a sample of yarn.lock

lru-native2@^1.2.0:
  version "1.2.5"
  resolved "https://registry.yarnpkg.com/lru-native2/-/lru-native2-1.2.5.tgz#06ad02a631c18426f31fdca9dd827a8e6fdbb4ca"

I would like to avoid modifying the yarn lockfile, but at this point, I am up to that if nothing else works.

Any workarounds/ guide on how to install the missing libraries from src?

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • Remember that you're linking to an open source project: [did you ask them about this?](https://github.com/kibae/node-lru-native/issues) because the odds that you're the only person affected are pretty low, and making sure the code author's aware of this problem is pretty important. That said, your edit makes it sound like you solved the problem, and without anyone's help, so... time to delete your post? Or post that "edit" as a proper answer instead. Questions should never have an "edit" heading, either you work the missing details in the post, or it's an answer. – Mike 'Pomax' Kamermans Sep 01 '22 at 16:50
  • Thanks @Mike'Pomax'Kamermans, I extracted the "EDIT" into a separate answer. Out of curiosity, I would still like to know how to update the `GCC` libraries manually, but my "problem" was circumvented with the answer I wrote below. – Guilherme Morgado Sep 01 '22 at 17:02
  • you'll probably want to start by updating your Dockerfile to explicitly install it (see https://stackoverflow.com/a/70990697/740553). – Mike 'Pomax' Kamermans Sep 01 '22 at 18:25
  • I did try to get a `apt update` and some extra commands to be able to add ppa's, and despite finding them on [debian repos](https://packages.debian.org/buster/libstdc++6), I couldnt figure how to install them. Doing an explicit `sudo apt-get upgrade libstdc++6` didnt change any versions. The [Debian Buster documentation for libstdc++6](https://packages.debian.org/oldstable/amd64/libstdc++6/filelist) it shows that it gets up to .25. The needed version seems to come with `gcc-11` [according to this](https://askubuntu.com/questions/1393285/how-to-install-glibcxx-3-4-29-on-ubuntu-20-04) – Guilherme Morgado Sep 01 '22 at 20:48
  • You can also just install wget or curl, get the source tar.gz for the version you need, and then run the configure/make steps as part of your Dockerfile. More commands, but ultimately Docker images are "build once, then use lots" far more than they are constant rebuilding. – Mike 'Pomax' Kamermans Sep 01 '22 at 21:36

1 Answers1

1

Seems like idiot me did a local yarn, which updated the yarn.lock (I should have used yarn install --frozen-lockfile, I was just following the README installation instructions).

This overwritten yarn.lock was then being passed into my container (node:16, based on Debian Buster) and module resolution based on my local version of node_modules uses different C++ libraries than what it should use inside the container.

Resetting my yarn.lock (or, alternatively, deleting it and letting the Container generate a new one, which I would recommend against) solved the issue.