bstaletic
commented
5 years ago This is surprising. Can you show us what's in your global extra conf? Are you doing anything that requires ycm_core to be loaded in your extra conf?
Closed rmrao closed 5 years ago
bstaletic
commented
5 years ago This is surprising. Can you show us what's in your global extra conf? Are you doing anything that requires ycm_core to be loaded in your extra conf?
rmrao
commented
5 years ago So I'm relatively new to using YCM with clang completion - I mostly do python development, so it's very possible I'm messing something up, although I tried replicating numerous times before submitting an issue.
To get up and running, I was trying the conf file from here. I had been able to replicate this issue though with both the ycmd extra conf and various conf files from several other projects (that aren't developed by me). See here and here (latter requires an academic license). I was also able to replicate this issue on a different machine (Ubuntu 16.04 and an older version of YCM that used libclang 7.0).
On the other hand, I just signed in to do some editing today and this doesn't seem to actually affect anything in terms of completion? At least, a lot of the basic completion commands like Goto are working.
rmrao
commented
5 years ago Just to follow up with some info I saw requested in a previous issue:
ldd ycm_core.so:
linux-vdso.so.1 (0x00007ffc053a0000)
libpython3.6m.so.1.0 => /home/rmrao/anaconda3/lib/libpython3.6m.so.1.0 (0x00007ffb02ada000)
libclang.so.8 => not found
libstdc++.so.6 => /home/rmrao/anaconda3/lib/libstdc++.so.6 (0x00007ffb037ec000)
libgcc_s.so.1 => /home/rmrao/anaconda3/lib/libgcc_s.so.1 (0x00007ffb037d8000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffb026e9000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ffb024ca000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ffb022c6000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007ffb020c3000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007ffb01ebb000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ffb01b1d000)
/lib64/ld-linux-x86-64.so.2 (0x00007ffb0375d000)objdump -x ycm_core.so | grep RPATH
^no output generated. Not clear if this is expected or not.
puremourning
commented
5 years ago So I think what's happening is that we're calling the global extra conf ( which imports ycm_core itself ) before loading ycm_core ourselves, and the global extra conf is also trying to load ycm_core.
This is not cool. It is not legitimate for global extra confs to import ycm_core in the global scope. The reason for this is a (legacy, undocumented) feature where global extra conf files can hook a "ycm core preload" hook which allows them to e.g. pre-load certain dlls (like, custom libclangs or something) before ycm_core.so is loaded into ycmd.
I don't think I would describe the linked extra conf as "better" personally, but you can probably fix it by moving the import to within the FlagsForFile (sic: should now be Settings) function.
Anyway, I would strongly recommend you don't copy/paste someone else extra conf file. Prefer to read the docs and either write your own or use a compilation database. For most people the later is easier, but the former should be a walk in the park for a python developer. All your Settings function has to do is return a dict with a single flags key which is a list of the compiler flags to use.
I think the problem would not happen with a trivial global extra conf such as the one in the docs:
def Settings( **kwargs ):
return { 'flags': [ '-x', 'c++' ] }Therefore I'm closing this. We can re-open if one of the following doesn't solve it"
akshit-sharma
commented
5 years ago I am having the same issue. I can open a separate issue and am just looking for some guidance on how to approach it.
Problem, I want to tackle:
I would like to know if it's possible to achieve the above without making any changes in the repository containing project?
Thank you
puremourning
commented
5 years ago Setting and FlagsForFile are equivalent. What I said was move the import to within the function so it happens after ycm core is properly loaded.
akshit-sharma
commented
5 years ago Oh, sorry. I didn't know it was possible to import inside a function. I also got confused between Setting and FlagsForFile because of different type of argument and overlooked the filename is also passed to Setting.
I tried having import ycm_core in starting function (Setting or FlagsForFile) but used it in a function called by starting function. So it wasn't found and I got confused. It just had to be in the same function which was using ycm_core.
Thanks for your time, I am able to get it working now.
Issue Prelude
Please complete these steps and check these boxes (by putting an
xinside the brackets) before filing your issue:vim --version.:YcmDebugInfo.:YcmToggleLogscommand.install.py(orcmake/make/ninja) including its invocationThank you for adhering to this process! It ensures your issue is resolved quickly and that neither your nor our time is needlessly wasted.
Issue Details
I've been attempting to use
ycm_global_ycm_extra_conf. It looks like when doing so, there's an issue with importingycm_core. I was able to reproduce this issue even when usingycmd's own.ycm_extra_conf.py.Case - No Global Conf
Open any file under
YouCompleteMe/third_party/ycmd/cpp/ycm/.:YcmDebugInfo
cat /tmp/ycmd_55403_stderr_ehon6wch.log
Case 2 - Global Conf = '${HOME}/.vim/.ycm_extra_conf.py'
mv .ycm_extra_conf.py ~/.vimlet g:ycm_global_ycm_extra_conf = ~/.vim/.ycm_extra_conf.pyto.vimrc:YcmDebugInfo
cat /tmp/ycmd_42243_stderr_fmxhmeyl.log
If I had to guess, the global conf is loaded before YCM updates the system path to include LIBCLANG_DIR, which causes the failure (just a guess based on the error and the fact that LIBCLANG_DIR does have to be added to the path I think?).
Diagnostic data
Output of
vim --versionContents of YCM, ycmd and completion engine logfiles
Included above
OS version, distribution, etc.
Ubuntu 18.04.