More cleanup for armhfp and aarch64 rpm hardcoded dependencies#111253
More cleanup for armhfp and aarch64 rpm hardcoded dependencies#111253joaomoreno merged 2 commits intomicrosoft:masterfrom
Conversation
…ilable in CentOS7 and CentOS8
…ly available in CentOS7 and CentOS8, may need more work
|
Thanks a lot @psgreco! What do you mean by the following?
Anything we can/should do here? |
You need to build the binaries using an older version of libstdc++, the binaries have real references a libstdc++ version that will never be available in CentOS7 (not the hardcoded ones for your rpms). I'm guessing you're not using CentOS7 to build. If you can't do this, maybe you'll need to provide an alternative solution (like static binaries or providing a compatible libstdc++.s.6) There's a small hack I use to check for this stuff (real hack, hehe) Which means I already have the needed lib (/lib64/libstdc++.so.6) but it doesn't provide the needed version. |
|
Got it, thanks! I'm guessing this is an issue in x64 as well. Related, wrt to server: microsoft/vscode-remote-release#2998 |
|
Yes, sounds like the same issue, and also yes, using an older debian should fix this, though I'd rather use CentOS since IIUC jessie is EOL since Jun 2020. If you need newer versions of things (like gcc), you could activate the necessary "devtoolsets" and still keep the compatibility with the base libstdc++ version. I'm talking about using gcc 7, 8 or 9 instead of the default 4.8.5 |
Continuing with #111198 there is some more cleanup to be done in the hardcoded dependencies. If I'm not mistaken, with this cleanup, the build I tested doesn't have any missing deps to run in CentOS8.
Wrt CentOS7, there are some missing deps in
libstdc++.so.6(like GLIBCXX_3.4.20 and CXXABI_1.3.9), but those should be fixed at build time.Related to RPM part of #106473