issues including libstdc++ (or how to get eaten by a grue)

[geiseri]

I just installed the Debian package of code server on Ubuntu Eoan and any C++ application that tries to run as a child of code server is now broken with the following error:

cmake: /usr/lib/code-server/bin/../lib/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by cmake)
cmake: /usr/lib/code-server/bin/../lib/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by cmake)
cmake: /usr/lib/code-server/bin/../lib/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by cmake)
cmake: /usr/lib/code-server/bin/../lib/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by cmake)
cmake: /usr/lib/code-server/bin/../lib/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /lib/x86_64-linux-gnu/libjsoncpp.so.1)

This is because the libstdc++ included is only at ABI level CXXABI_1.3.8 and in my case, libjsoncpp was linked against a symbol first only found in CXXABI_1.3.9. If I remove that libstdc++ from code it all works again.

Traditionally statically linking (or just flat out including) libstdc++ is a disaster.

<rant>
Why it is 2020 and this has been a problem for since the first time we had dynamic linking can only be attributed to the C++ standards committee hating people who ship software and the GCC authors being sadists who enjoy torturing kitten when they are not torturing developers. While #1706 was a noble dream, it will break so much more than you will fix, your hampster will leave you, your house will burn down, you will die alone, and more than likely be writing a bug report like this in 5 years for someone else's project.
</rant>

In the end, what people end up doing is either run the entire application stack with the same versions aka flatpak/snap, or they go the appimage route and compile against the oldest version of libstdc++ they can compile on. The issue with flatpak/snap approach is fraught with danger in something like code-server since it will run toolchains and other things inside of a different env. One approach might be to use the above link along with some magic to take the parent library path and then pass that down into the child environments when tasks run. See http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths for the first steps down the path to that madness. In my tortured experience of packaging C++ software on Linux for the last 15 years, you are best off with the link your app against the oldest libc++ you can possibly support and hope for the best :( https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html has the details you need to start down that path.

[nhooyr]

Why it is 2020 and this has been a problem for since the first time we had dynamic linking can only be attributed to the C++ standards committee hating people who ship software and the GCC authors being sadists who enjoy torturing kitten when they are not torturing developers. While #1706 was a noble dream, it will break so much more than you will fix, your hampster will leave you, your house will burn down, you will die alone, and more than likely be writing a bug report like this in 5 years for someone else's project.

😂 facts

Sorry about this, but I think we can safely fix it but unsetting DYLD_LIBRARY_PATH and LD_LIBRARY_PATH after code-server starts up. That way any application you run will not inherit our modified variables.

[nhooyr]

@code-asher How will this interact with VS Code's subprocesses? Is there a way to only unset the variables when spawning a terminal or a user command?

[code-asher]

VS Code has some code to sanitize the environment when spawning a terminal.

https://github.com/microsoft/vscode/blob/1.45.1/src/vs/base/common/processes.ts#L109

But it doesn't apply to any other processes spawned by VS Code unfortunately.

[nhooyr]

So anything launched by a plugin would still have it set?

[code-asher]

Yep.

[nhooyr]

New release is out!