Regression in ycm_core rpath on Linux

[no-more-secrets]

Looks like commit a6c95a2ff7fd2600e37851a527ca01a972d41e0b might have broken dynamic loading of the ycm_core shared object on Linux when using a custom Clang installation. This prevents YCM from working since when it tries to load that shared library it cannot locate libclang.so.13 and fails. The commit description mentions that it is intended for mac, but it looks like it's just testing for "not MSVC", which includes Linux.

Specifically, when I update past this commit in my local copy and build YCM using my usual command:

$ EXTRA_CMAKE_ARGS="-DPATH_TO_LLVM_ROOT=/path/to/llvm" ./install.py --clang-completer

Then I get the following when inspecting the ycm_core binary:

$ cd ~/.vim/bundle/youcompleteme/third_party/ycmd
$ ldd ycm_core.cpython-38-x86_64-linux-gnu.so
        linux-vdso.so.1 (0x00007ffea71e1000)
        libpython3.8.so.1.0 => /lib/x86_64-linux-gnu/libpython3.8.so.1.0 (0x00007f052c586000)
        libclang.so.13 => not found
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f0526123000)
        ...

(note the "not found"). Even though I have the libclang.so.13 symlink in the same folder. When I revert that commit in my working copy and rebuild YCM with the same command, then it works fine, as before, since it has the correct rpath pointing directly to the libclang.so.13 in the same folder.

The commit mentioned above guards its logic with the following:

if ( NOT MSVC )
  ...
endif ()

When I change it to the following it fixes the problem:

if ( NOT MSVC AND NOT UNIX )
  ...
endif ()

@Chilledheart FYI

[no-more-secrets]

Should mention that the "fix" that I proposed above (adding AND NOT UNIX) obviously fixes it for me because it disables that logic from running on my system, but I'm not sure if that would be the right general fix, will leave that up to the authors.

[puremourning]

I can't reproduce this. Please can you give steps to reproduce in a specific environment (e.g. container, vm) etc.

[no-more-secrets]

After more investigation, I've found another issue: when I give the YCM build script the path to my LLVM build (very recent version, containing clang 15) it "incorrectly" links the ycm_core binary to libclang.so.13. I do this (I'm on Ubuntu 20.04) by setting the following before running the install script:

# This path contains a recent full llvm/clang build containing clang 15.  To recent?
path=/path/to/my/llvm-root

$path/bin/clang --version
clang version 15.0.0 ...

export EXTRA_CMAKE_ARGS="-DPATH_TO_LLVM_ROOT=$path"
./install.py --clang-completer

Then build succeeds, but the resulting ycm_core binary is linked instead to libclang.so.13, which does not exist, since my llvm/clang is version 15. So even if I want to manually create symlinks in the ycm_core's rpath folder to tell it where the libclang binary is, it will have the wrong version.

I think we can close this particular issue since what I described is not the real problem that I'm seeing, instead it might be a question of linking to the wrong libclang version. Do you think I should raise a separate issue for that?

[puremourning]

Didn't llvm recently change their policy regarding soversions so that it only changes when libclang actually changes compatibility?

[puremourning]

Tbh my advice would be to ditch the legacy libclang completed and switch to clangd for tons more features and better performance etc etc.

We will not be investing hardly any effort in the legacy mode.

[no-more-secrets]

Ok, yeah probably time to switch to clangd then. Thx