Version 7.7.0 of keytar breaks older Linux distributions (incl. RHEL7)

[colin-grant-work]

Bug Description:

The keytar package introduced to our dependencies in #9463 depends on different versions of the standard library depending on release. While 7.6.0 works on RHEL7, 7.7.0 doesn't, and kills the startup with an error like the following:

Error: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found

Most advice online suggests that users upgrade their distribution, but that isn't always possible in a corporate context. Downstream, we can add this to our resolutions, but we might want to consider using 7.6.0 in the framework to keep things simple and reduce 'gotcha's for adopters working on various platforms unless there's a good reason to prefer 7.7.0.

• Operating System: RHEL7
• Theia Version: Apply Secrets plugin API #9463 and later

[colin-grant-work]

@vinokurig, do you have any thoughts about this?

[kittaakos]

do you have any thoughts about this

Hey, just chiming in, I'd have a few questions:

and kills the build / startup

Is it a build or runtime issue? It's unclear.

Most advice online suggests that users upgrade their distribution

Can you please share a few links with the community? What did you try?

to keep things simple for users unless

users

Who do you consider as the user in the context of this issue:

• a core committer building the project from the sources,
• an extension developer using a pinned version (or next),
• someone building a Theia-based app from a package.json, or
• the end-user downloading an electron app.

Please share some details. Thank you!

[colin-grant-work]

Is it a build or runtime issue? It's unclear.

Runtime. I said build initially and then remembered that it was actually runtime, but was going to circle back and check. The build is successful, but startup fails.

Most advice online suggests that users upgrade their distribution

Can you please share a few links with the community? What did you try?

atom/atom#21860
coder/code-server#347
https://askubuntu.com/questions/575505/glibcxx-3-4-20-not-found-how-to-fix-this-error
https://www.programmersought.com/article/83955397274/

Most say either upgrade your distribution or install / compile a newer version of the standard library. We aren't able to do either, though many could. My team went with a resolution strategy pretty quickly, because that's easy to implement for us even when we have very little control over our environment.

Who do you consider as the user in the context of this issue:

I've changed to the word 'adopter', but here are my thoughts:

• a core committer building the project from the sources,
• an extension developer using a pinned version (or next),
• someone building a Theia-based app from a package.json, or
• the end-user downloading an electron app.

The problem could affect someone in any of those positions (incl. the end-user, if the publisher didn't check / didn't publish a separate binary), since it's a runtime crash.

[kittaakos]

Thanks! What about keeping the versions in-sync with VS Code: https://github.com/microsoft/vscode/blob/94463fabc296d242eaa80558630790012471cc8a/package.json#L67

[paul-marechal]

@colin-grant-work keytar seems to be using https://www.npmjs.com/package/prebuild-install in order to pull the native addon rather than building it on install. Most other of our native packages build themselves on install. Using the various environment variables, are you able to build keytar.node and then point to it when running your application?

My hope is that the build will either fail because of reasons which can be fixed and upstreamed, or the build will work and then the package should also work in the same environment it was built in.