codelldb prebuilt version too new for RHEL 7

[LEgregius]

OS: Red Hat Enterprise Linux 7.8 VSCode version: 1.42.1 Extension version: 1.5.0 or in native mode in older versions Toolchain version: Clang 7.0.1 Build target: x86_64-redhat-linux Python version: 3.6.8

With the removal of the "classic" mode, the debugger fails to start. It appears that the codelldb executable was built with glibc-2.18, but RHEL 7 uses 2.17. I'm stuck on RHEL 7 for the time being. I'll have to stay on an older version unless the code is built with an older glibc. I'll be happy to put some effort into building the library if this isn't something you can solve easily.

Debug log

liblldb: /opt/rh/llvm-toolset-7.0/root/lib64/liblldb.so.7
libpython: null
environment: {}
params: {}
/home/dguthrie/.vscode/extensions/vadimcn.vscode-lldb-1.4.5/adapter2/codelldb: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by /home/dguthrie/.vscode/extensions/vadimcn.vscode-lldb-1.4.5/adapter2/codelldb)
Error: The debugger exited without completing startup handshake.

[SindreSB]

Hi, I'm seeing a similar issue on MacOS:

Error: "\"dlopen(/Users/xxx/.vscode/extensions/vadimcn.vscode-lldb-1.5.0/lldb/lib/liblldb.dylib, 9): Library not loaded: /usr/local/opt/xz/lib/liblzma.5.dylib\\n  Referenced from:  Users/xxx/.vscode/extensions/vadimcn.vscode-lldb-1.5.0/lldb/lib/liblldb.dylib\\n  Reason: Incompatible library version: liblldb.dylib requires version 8.0.0 or later, but liblzma.5.dylib provides version 6.0.0\""
Error: The debugger exited without completing startup handshake.

This is not on my machine, but two students in our C++ course reported such errors yesterday. Is it related, or perhaps a different issue?

[vadimcn]

@LEgregius: Yeah, the only option right now is to upgrade glibc to v2.18.

@SindreSB: This is a somewhat similar issue, but let's keep them separate. I've created #270 to track this. Can you please provide OS version?

[vadimcn]

@LEgregius: The other option is of course to downgrade codelldb to 1.4.5 and keep using classic adapter.

[LEgregius]

I am running 1.45, but I don't want to remain on an old version forever. Upgrading glibc isn't really an option. It would affect the entire system to do that, and would end up causing the binaries I compile to not be compatible with a deployed system. It would be possible to ship a version of glibc with codelldb, but it would have to be built to look for glibc in a nonstandard place. It also might be possible to build it with one of libc replacement libraries and statically link it. I was trying to build a replacement copy of codelldb myself. Maybe I could just replace the path to it. Is there anything special about your version that I can't just it with another one?

[dawid-s]

@LEgregius Just FYI, I was able to successfully build glibc-2.18 without affecting the system by installing it to /opt/glibc-2.18 using these instructions: https://stackoverflow.com/a/38317265/3316999

In addition, I had to go and patchelf all the binaries inside the extension folder (such as codelldb, libcodelldb.so, etc.) to set the interpreter/loader and rpath:

patchelf --set-interpreter /opt/glibc-2.18/lib/ld-linux-x86-64.so.2 --set-rpath $HOME/.vscode/extensions/vadimcn.vscode-lldb-1.5.3/lldb/lib:/opt/glibc-2.18/lib:/usr/lib64 vadimcn.vscode-lldb-1.5.3/lldb/lib/liblldb.so

This way only these binaries would use newer glibc without affecting anything, even VSCode. Hope that helps.

[justintime4tea]

patchelf --set-interpreter /opt/glibc-2.18/lib/ld-linux-x86-64.so.2 --set-rpath $HOME/.vscode/extensions/vadimcn.vscode-lldb-1.5.3/lldb/lib:/opt/glibc-2.18/lib:/usr/lib64 vadimcn.vscode-lldb-1.5.3/lldb/lib/liblldb.so

~Can you post the set of commands you used for this? I'm not familiar enough with patchelf but I am getting a "patchelf: cannot find section '.interp'. The input file is most likely statically linked" and I'm sure there are more commands than just that I would need.~

Thanks in advanced! ~Will continue to tinker.~

UPDATE (works as of 1.6.1)

_I don't know enough about LDPRELOAD, library linking, GLIBC, and libgcc to know if anything below may render parts of your system in a "bad" state. This was all performed inside a CentOS 7 VM

• Build glibc-2.18

  cd /opt/
  wget http://ftp.gnu.org/gnu/glibc/glibc-2.18.tar.gz
  tar zxvf glibc-2.18.tar.gz
  cd glibc-2.18
  mkdir build
  cd build
  ../configure --prefix=/opt/glibc-2.18
  make -j4
  sudo make install

• Update the interpreter used by bundled codelldb, lldb-server, and lldb (host machine debugging)

  
  patchelf --set-interpreter /opt/glibc-2.18/lib/ld-linux-x86-64.so.2 $HOME/.vscode/vadimcn.vscode-lldb-1.6.1/adapter/codelldb

patchelf --set-interpreter /opt/glibc-2.18/lib/ld-linux-x86-64.so.2 $HOME/.vscode/vadimcn.vscode-lldb-1.6.1/lldb/bin/lldb-server

patchelf --set-interpreter /opt/glibc-2.18/lib/ld-linux-x86-64.so.2 $HOME/.vscode/vadimcn.vscode-lldb-1.6.1/lldb/bin/lldb

  * For remote machine debugging (like Cent/RHEL in a VM and using VS Code remote ssh you need to replace $HOME/.vscode with $HOME/.vscode-server in the above snippet
* Install libgcc if you don't already have it installed
  * yum install -y libgcc
* VS Code set to "interactive" so that /etc/profile.d/* are loaded
  * This may only be needed in the case of remote SSH debugging
  * To make shell interactive add to settings.json

"terminal.integrated.shellArgs.linux": [ "-l" ],

* Create with below content (or add to) /etc/profile.d/rust.sh
  * LD_PRELOAD=/usr/lib64/libgcc_s.so.1
  * This may only be necessary for remote debugging
  * This may cause other issues that I'm naively unaware of
* Some similar launch.json to the following:

{ "version": "0.2.0", "configurations": [ { "type": "lldb", "request": "launch", "name": "Debug", "program": "${workspaceRoot}/target/debug/example-bin", "args": [], "cwd": "${workspaceRoot}", "sourceLanguages": [ "rust" ] }, ] }

If you use Rust VS code extension and want to use rust-analyzer (spiritual succesor?) it also won't work  however if you use the `rust-analyzer` VS Code extension you can perform the same interpreter and LD_PRELOAD steps above. Additionally I had to add LD_PRELOAD to my `.bashrc`. Replace `.vscode-server` with `.vscode` if not running on a remote host.

patchelf --set-interpreter /opt/glibc-2.18/lib/ld-linux-x86-64.so.2 $HOME/.vscode-server/data/User/globalStorage/matklad.rust-analyzer/rust-analyzer-x86_64-unknown-linux-gnu

[dpar39]

For the record, the trick of patching the binaries only worked until version 1.6.3 of the extension. Newer versions will throw an error with dlopen.

I can confirm that on CentOS 7 patching as described above works:

export LIB_DIR=$HOME/glibc-2.18/lib
export CODE_LLDB_ROOT=$HOME/.vscode-server/extensions/vadimcn.vscode-lldb-1.6.3
patchelf --set-interpreter $LIB_DIR/ld-linux-x86-64.so.2 --set-rpath $LIB_DIR:$CODE_LLDB_ROOT/lldb/lib:/usr/lib64 $CODE_LLDB_ROOT/adapter/codelldb
patchelf --set-interpreter $LIB_DIR/ld-linux-x86-64.so.2 --set-rpath $LIB_DIR:$CODE_LLDB_ROOT/lldb/lib:/usr/lib64 $CODE_LLDB_ROOT/lldb/bin/lldb-server
patchelf --set-interpreter $LIB_DIR/ld-linux-x86-64.so.2 --set-rpath $LIB_DIR:$CODE_LLDB_ROOT/lldb/lib:/usr/lib64 $CODE_LLDB_ROOT/lldb/bin/lldb