Dear Maintainer,

The Clang plugin seems to be responsible for advanced syntax highlighting and
probably other features. I just updated packages on my system and noticed these
features no longer work. I saw a few copies of the below in the kdevelop output
to console:

kdevplatform.shell: Could not load plugin "kdevclangsupport" , it reported the
error: "The clang builtin include path
\"/usr/lib/llvm-11/lib/clang/11.0.0/include\" is invalid (missing cpuid.h
header).\nTry setting the KDEV_CLANG_BUILTIN_DIR environment variable manually
to fix this.\nSee also: https://bugs.kde.org/show_bug.cgi?id=393779" Disabling
the plugin now.

So the path it needs is hard-coded and versioned, for 11.0.0 in the present
binary. My latest update pulled in Clang 11.0.1. If I set the
KDEV_CLANG_BUILTIN_DIR variable correctly and run kdevelop, then it works.

The KDE bug linked above does seem related, but ends with closure despite more
run-time checking being a TODO. Until that's implemented, it seems the Clang
plugin has a hard-ish version dependency on Clang, and the kdevelop package
must be rebuilt when Clang updates, or the user has to employ the environment
variable workaround.

Peace,
Brendon

I discovered that creating:

sudo ln /usr/bin/llvm-config-11 /usr/bin/llvm-config

Allows KDevelop to work properly.
So maybe an update-alternatives could be involved or just link(s) set up during the install of llvm.

Justin Jones

Oops...  ignore the llvm-config solution I posted earlier.

I dug into the source. I can see where another guess at the path could be made or one of the existing 3 could be loosened up to match the output of Debian's clang-11  --version output.

Details:

In KDevelop source:   plugins/clang/duchain/clanghelpers.cpp

QString ClangHelpers::clangVersion(){
...
QRegularExpression re(QStringLiteral("^clang version (\\d+\\.\\d+\\.\\d+)"));
...
}

The regular expression won't match as the Debian version of clang-11 has the  line starting with 'Debian clang' instead of just 'clang'

This bug can be closed. No longer an issue with KDevelop 5.6.2.

Fixed in KDevelop git commit fa83c76b133a52c8ce0e7af0aa8c060fadaa8536

Background:
Debian and Ubuntu (and others?) have unique clang --version output.
KDevelop tries a few different ways to determine the clang include directory. The most successful method seems to be matching on the output of the 'clang --version' output (which the developers recognize as unsafe ).

control: fixed -1 4:5.6.2-4

Thanks for the follow up.
Closing as per your request.

What I read from upstream git log is that the commit you mention is on master
and the fix was actually backported to the 5.6 branch as
4688d626c145711e35f3676dbd4c827b3b2ea7f6.

It’s not been released on that branch yet but we already have the fix in
Debian because Pino took care to backport it into 4:5.6.2-4.


Happy hacking !
--
Aurélien

reopen 981679
thanks

Hi,

In data giovedì 11 febbraio 2021 10:18:14 CET, Aurélien COUDERC ha scritto:

The upload of kdevelop 4:5.6.2-4 fixes what Justin reported, i.e. that
the clang plugin cannot parse the clang version string in more recent
Debian clang versions. The original problem, though, is totally
different: the clang plugin hardcodes the clang include directory and
the clang version and, while it appears to have some logic to handle
runtime version bumps, it seems it cannot fully cope with this
situation. It looks like there is no more issue simply because the
upload of kdevelop 5.6.2 (starting with 4:5.6.2-1) rebuilds with the
latest clang, so it makes the problem "go away" until the next time
the default clang version (currently 11) is updated in Debian.
Because of this, the actual problem reported in this bug report
*is* still valid, and I hope upstream can do something about it so
we (in Debian) don't get breakages on clang version bumps. Luckly,
I did changes in the packaging so it is possible to binNMU (i.e. a
plain no-changes rebuild) kdevelop in such situations, and the rebuilt
kdevelop will not migrate to testing until the newer clang version
migrated too; it is mostly a workaround though.

Julien: while I thank you for spotting the issue with the parsing of
clang version string, I strongly recommend you to report *new* bugs for
problems different that what reported. It is always easier to merge
bugs in case they are actually the same issue, while adding different
and unrelated issues to a bug makes it really hard to properly track
what is fixed and what is not.

Thanks,