Version 1.7.0 (insiders) of extension now requires an OS with glibc 2.27 or newer

[ChenCuiPlasma]

Bug type: Language Service

Describe the bug

• OS and Version: Ubuntu 16.04 LTS
• VS Code Version: 1.60.2
• C/C++ Extension Version: 1.7.0-insider
• A clear and concise description of what the bug is, including information about the workspace (i.e. is the workspace a single project or multiple projects, size of the project, etc):
  After the update of 1.7.0-insider extension this afternoon, the language server of C/C++ extension continues to crash and it notifies that "version `GLIBC_2.27' not found", I assume this comes with the compatibility with the Ubuntu 16.04 system

Expected behavior

The IntelliSense stops to work after the crash of the language server

[sc420]

Got same issue with v1.7.0-insiders on CentOS 7:

.../.vscode-server/extensions/ms-vscode.cpptools-1.7.0-insiders/bin/cpptools: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by .../.vscode-server/extensions/ms-vscode.cpptools-1.7.0-insiders/bin/cpptools)

I downgraded it to v1.6.0 and disabled the extension auto-update, it works fine now.

[nolongerwait]

same issue with v1.7.0-insiders on Debian 9

/home/????/.vscode-server/extensions/ms-vscode.cpptools-1.7.0-insiders/bin/cpptools: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.27' not found (required by /home/????/.vscode-server/extensions/ms-vscode.cpptools-1.7.0-insiders/bin/cpptools)

[nolongerwait]

How to set it to find libs according to the configured path, Rather than the system default? Since our develop environment has multiple sets of compilation environments, I specified C_Cpp.compilePath, but it obviously didn't take effect.

[lixin-wei]

same issue in CentOS 7. Could you please keep the compatibility to gdbc <= 2.24? It's hard to upgrade glibc.

/home/admin/.vscode-server/extensions/ms-vscode.cpptools-1.7.0-insiders/bin/cpptools: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by /home/admin/.vscode-server/extensions/ms-vscode.cpptools-1.7.0-insiders/bin/cpptools)

I have to downgraded it to v1.6.0.

[ChenCuiPlasma]

I also downgrade the version back to 1.60. Upgrade glibc for the system may result in the disability of boot process... so if it is possible please check the compatibility of the glibc of the cpp extension.

[jhsterling]

How do I disable auto update of the extension? I download and install v1.6 but then it auto updates to v1.7

[lixin-wei]

@jhsterling It's here:

[jhsterling]

@lixin-wei
Got it. Thanks.

[perrog]

Same problem for me.

• OS and Version: CentOS Linux release 7.9.2009 (Core)
• VS Code Version: 1.60.0

[michelleangela]

There was a build change for version 1.7.0 because Azure Ubuntu 16 build pool is no longer available. Because of the build change, version 1.7.0 of the extension now requires an OS with glibc 2.27 or newer.

Sorry we failed to communicate this requirement as we were not sure if it would be an actual issue.

To continue to use version 1.6.0 of the extension without auto-updating to 1.7.0, disable the setting extensions.autoUpdate.

A request to add back the Azure Ubuntu 16 image build pool can be filed at https://github.com/actions/virtual-environments.

[ykuchin]

Same on Oracle Linux 7

[sean-mcmanus]

The root cause is from actions/runner-images#3287 (we haven't yet found a way to keep the older glibc dependency when building on Ubuntu 18).

[perrog]

Thanks for the answers. I checked with objdump -T and it seems to be the powf() function in cpptools that needs glibc 2.27. Maybe I misinterpret the output from objdump or dont understand .so versioning on Linux, but if it happens to be just powf() usage maybe one could roll one’s own power function to keep backward compatibility with older distros? Or maybe there is a way to add glibc 2.27 on my CentOs 7 devcontainer? (Yes, I’m running cpptools 1.6.0 for now but I’m eager to use the latest preview builds since it always improve and becoming better)

[nolongerwait]

There was a build change for version 1.7.0 because Azure Ubuntu 16 build pool is no longer available. Because of the build change, version 1.7.0 of the extension now requires an OS with glibc 2.27 or newer.

Sorry we failed to communicate this requirement as we were not sure if it would be an actual issue.

To continue to use version 1.6.0 of the extension without auto-updating to 1.7.0, disable the setting extensions.autoUpdate.

A request to add back the Azure Ubuntu 16 image build pool can be filed at https://github.com/actions/virtual-environments.

So, anyone can answer my question?....How to set it to find libs according to the configured path, rather than use system default? Since our develop environment has multiple sets of compilation environments, I specified C_Cpp.compilePath, but it obviously didn't take effect.

[sean-mcmanus]

@perrog Yes, you are correct -- the powf is the cause of the 2.27 requirement and without that it would drop to 2.17. It was on my TODO list to check that via readelf -a, but I was working other stuff and forgot about it. We may be able to fix it via avoiding the call to powf as you suggested. UPDATE: We have a fix, but it still needs to go through our code review and release process.

@nolongerwait I'm not sure what you're asking. The compilerPath is for configuring IntelliSense and is unrelated to this glibc issue.

[lixin-wei]

@sean-mcmanus How you fixed this? By using your own power function?

[sean-mcmanus]

@lixin-wei Yes...we only call it in the simple pow(float, int) case.

[nolongerwait]

@sean-mcmanus Which config setting is related to this GLIBC issue? I mean that there are multiple compilation environments in my development environment, and there are different versions. I want to know whether I could use the configuration of vscode-cpptools to make it find the correct libc file or not? while, I don’t want to modify the default parameters of the system.

[sean-mcmanus]

@nolongerwait No config setting is related to the glibc issue -- it's an issue with the cpptools binary. We'll be releasing a fix with 1.7.0-insiders2 tomorrow.

[zjwangmin]

@nolongerwait No config setting is related to the glibc issue -- it's an issue with the cpptools binary. We'll be releasing a fix with 1.7.0-insiders2 tomorrow.

Thanks a lot.

[michelleangela]

1.7.0-insiders2 is now available with a fix for this issue. https://github.com/microsoft/vscode-cpptools/releases/tag/1.7.0-insiders2

[Colengms]

Since this was a regression only in a previous insiders release, closing this issue.

[nolongerwait]

@nolongerwait No config setting is related to the glibc issue -- it's an issue with the cpptools binary. We'll be releasing a fix with 1.7.0-insiders2 tomorrow.

Get it, Thanks for your reply.😁