sourcery-vscode

sourcery-vscode copied to clipboard

I have a server I sometimes use the VSCode "Remote SSH" extension with to connect to and when I do Sourcery is not happy:

[Info  - 4:09:34 PM] Connection to server got closed. Server will restart.
Traceback (most recent call last):
  File "/home/alan/.vscode-server/extensions/sourcery.sourcery-0.12.1/sourcery_binaries/install/linux/__main__.py", line 8, in <module>
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
  File "/home/alan/.vscode-server/extensions/sourcery.sourcery-0.12.1/sourcery_binaries/install/linux/binary/command_line_interface.py", line 25, in <module binary.command_line_interface>
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
  File "/home/alan/.vscode-server/extensions/sourcery.sourcery-0.12.1/sourcery_binaries/install/linux/sourcery/code/file_ast.py", line 11, in <module sourcery.code.file_ast>
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
  File "/home/alan/.vscode-server/extensions/sourcery.sourcery-0.12.1/sourcery_binaries/install/linux/sourcery/code/source_parser.py", line 41, in <module sourcery.code.source_parser>
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
  File "/home/alan/.vscode-server/extensions/sourcery.sourcery-0.12.1/sourcery_binaries/install/linux/sourcery/code/tree_sitter/parser.py", line 90, in <module sourcery.code.tree_sitter.parser>
  File "/home/alan/.vscode-server/extensions/sourcery.sourcery-0.12.1/sourcery_binaries/install/linux/sourcery/code/tree_sitter/parser.py", line 56, in parse_source_to_ast
  File "/home/alan/.vscode-server/extensions/sourcery.sourcery-0.12.1/sourcery_binaries/install/linux/sourcery/code/tree_sitter/parser.py", line 67, in parse_source
  File "/home/alan/.vscode-server/extensions/sourcery.sourcery-0.12.1/sourcery_binaries/install/linux/sourcery/code/tree_sitter/parser.py", line 75, in make_parser
  File "/home/alan/.vscode-server/extensions/sourcery.sourcery-0.12.1/sourcery_binaries/install/linux/sourcery/code/tree_sitter/parser.py", line 84, in get_language
  File "/home/alan/.vscode-server/extensions/sourcery.sourcery-0.12.1/sourcery_binaries/install/linux/tree_sitter/__init__.py", line 82, in __init__
  File "/home/alan/.vscode-server/extensions/sourcery.sourcery-0.12.1/sourcery_binaries/install/linux/ctypes/__init__.py", line 452, in LoadLibrary
  File "/home/alan/.vscode-server/extensions/sourcery.sourcery-0.12.1/sourcery_binaries/install/linux/ctypes/__init__.py", line 374, in __init__
OSError: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /home/alan/.vscode-server/extensions/sourcery.sourcery-0.12.1/sourcery_binaries/install/linux/languages.so)

If it helps, the linux box runs CentOS7 and has libstdc++-4.8.5

> cat /etc/os-release
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

> rpm -qa | grep libstd
libstdc++-4.8.5-44.el7.x86_64
libstdc++-devel-4.8.5-44.el7.x86_64

Hi @darkvertex ,

Thanks a lot for reporting this issue and for the detailed information. :+1: This is definitely a :bug: , we'll look into it.

How long have you experienced this problem? Only for the version 0.12.1 (in the last 2 weeks) or longer?

Hi @darkvertex ,

Thanks again for reporting this. Unfortunately, our new parser relies on libstdc++ 6.

So far, we have 2 troubleshooting ideas:

1. Can you perhaps update the libstd version on your server?

2. Can you eventually upgrade glibc? We've seen a few instances of similar errors on various Linux versions, but all of them are using glibc 2.17

This is a shared server that's meant to match the general platform of our other systems and so I would probably piss off my peers by upgrading libs. Also the version I have is the newest available under CentOS7 out of the box, so I'd have to go out of my way to find and recompile a newer rpm.

I'm not a C++ expert but would it be crazy to bundle a newer libstd .so in your extension install's root directory so you don't depend on the system's one being right? Or statically linking against it for that matter?

Hello,

Thanks for the useful and creative extensions. I also had this error: OSError: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found so how to solve it? many thanks

This prevents using the plugin with Centos7. I haven't found a workaround.

Hello everyone, has this bug been fixed? Actually, I still had the bug

Hi @Chiu-Ping! This issue seems hard to fix, given how we currently build and release Sourcery. It is in our roadmap to address it, but it may take some time.

i believe this is about gcc. maybe an update . i'll try that and keep you posted

I've found a workaround

$ sudo find / -name 'libstdc++.so.6'
$ sudo unlink /usr/lib64/libstdc++.so.6
$ sudo cp /usr/local/lib64/libstdc++.so.6 /usr/lib64

If you are using vscode remote plugin , just quit and re-connect

i believe this is about gcc. maybe an update . i'll try that and keep you posted

Turns out it was a link problem

Still have this bug on remote ssh.

Seems that sourcery is not compatible with centos 7 , because of the libstdc++.so version. Centos 7 has version 2.18 maximum , and we can't install another version. I recommend to state this explicitly in the requirement.