Created attachment 118650 [details] Quick fix SUMMARY If I use Clang as backend for source parsing, none of the stdlib/libstdc++ headers on my system are found and parsing flat out fails as the maximum amount of parse errors is reached. This completely breaks code browsing and renders kdevelop virtually unusable on my system. (See ADDITIONAL INFORMATION for more details). STEPS TO REPRODUCE 1. Set Clang as compiler for Parsing Project -> Open Configuration -> Language Support -> C/C++ Parser -> Compiler for path = Clang 2. Open any project 3. See if includes are found and code browsing works OBSERVED RESULT None of the stdlib/libstdc++ headers are found, parsing fails, code browsing isn't working. EXPECTED RESULT Headers are found, code parsing and browsing works. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Archlinux/Plasma 5 KDE Plasma Version: 5.15.2 KDE Frameworks Version: 5.55.0 Qt Version: 5.12.1 KDevelop Version: 5.3.2 ADDITIONAL INFORMATION While digging around, I found out that this erroneous behavior only occurs on my system, if I use Clang as backend for parsing (which is the default). If I switch to GCC, it all works fine. Some further investigations and a direct comparison of kdevelop provided by my package manager and a custom kdesrc-build of the same revision that worked correctly showed, that the only difference was the PATH environment variable set during the start of kdevelop. In the kdesrc-build environment, kdevelop gets started like PATH=/usr/bin:/usr/local/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl kdevelop --ps which leads to enumeration of system include paths in the form of "/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../include/c++/8.2.1" which then gets correctly translated by class Path into "/usr/include/c++/8.2.1" Starting kdevelop provided by the package manager within the standard system environment looks like PATH=/bin:/usr/bin:/usr/local/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl kdevelop --ps which leads to enumeration of system include paths in the form of "/bin/../lib64/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../include/c++/8.2.1" which then gets translated by class Path into the non-existent path "/include/c++/8.2.1" The difference here being that the latter has /bin as first element of PATH. /bin is a symbolic link to /usr/bin, so the result should be the same. But apparently class Path doesn't properly resolve the symbolic link, which leads to the creation of non-existent include paths. I'm going to attach a quick and simple fix, but I'm not sure if this is the right way to do it. Maybe one of the devs could have a look.
Just wanted to keep you posted. The culprit turned out to be an old, leftover, auto-generated sddm.conf file that contained the line DefaultPath=/bin:/usr/bin:/usr/local/bin This made /bin the first element of PATH in all my user sessions and led to the faulty behavior as described above. With the new sddm.conf default DefaultPath=/usr/local/sbin:/usr/local/bin:/usr/bin the problem no longer occurs. But maybe we should apply the proposed patch anyway to make include path enumeration more robust?
See https://phabricator.kde.org/D23303
Git commit c315333c4aa38ec9d05f101844fc4729717fd13b by Milian Wolff, on behalf of Axel Kellerman. Committed on 20/09/2019 at 04:06. Pushed by mwolff into branch '5.4'. gcclikecompiler: properly resolve include paths with symbolic links Make sure include paths containing symbolic links are canonicalized - and thereby properly resolved - before wrapping them in a Path object. This is necessary, as class Path is not properly handling symbolic links. M +1 -1 plugins/custom-definesandincludes/compilerprovider/gcclikecompiler.cpp https://invent.kde.org/kde/kdevelop/commit/c315333c4aa38ec9d05f101844fc4729717fd13b