Created attachment 469352 [details, diff] Fix incorrectly assumed clang resource path From at least clang 4.0, gentoo installs clang resources in a non default path, i.e. in /usr/lib/clang instead of /usr/lib/llvm/4/lib/clang. Qt Creator assumes the default path for its clang code model. The attached patch fixes the problem. The real fix would be to query clang install path, but there does not seem to be a clang equivalent to llvm-config.
Also maybe clang'e ebuild could add something like ln -s /usr/lib/clang /usr/lib/llvm/4/lib64/clang to ensure that packages assuming the default installation path work correctly somehow.
/usr/lib/clang is actually the default path. A number of things hardcodes that.
There's 'clang -print-resource-dir' upstream can use to get the correct dir.
Oh I see what happens, Qt Creator expects llvm and clang to share the same install prefix. I was mislead by my own tests at compiling clang and llvm by hand, because I used the exact same convention.
(In reply to Michał Górny from comment #3) > There's 'clang -print-resource-dir' upstream can use to get the correct dir. $ clang -print-resource-dir clang-4.0: error: unknown argument: '-print-resource-dir' clang-4.0: error: no input files Can we simply use /usr/lib instead of $LLVM_LIBDIR?
Yes, that's reliable for Gentoo.
@llvm, in addition to the above, I guess I should use get_llvm_prefix from llvm.eclass instead of a plain `llvm-config --prefix`, right?
(In reply to Davide Pesavento from comment #7) > @llvm, in addition to the above, I guess I should use get_llvm_prefix from > llvm.eclass instead of a plain `llvm-config --prefix`, right? Yes, that would be preferable. It is acceptable not to use the eclass if you always support the newest slot (which gives the same result then).
Thanks. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f2b996694e4fd84d55a3f066eb30ca5e682a8720 https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ff777c4ebc7cfdc340a48bbbed7b1c070579b7d5