https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #45 from Kevin Funk ---
Git commit ec5477f351b6c4b25b7f6533314628ebdd7c2945 by Kevin Funk.
Committed on 05/10/2018 at 12:39.
Pushed by kfunk into branch '5.3'.
clang: Also detect Clang builtin dirs at runtime
Summary:
Changes:
* Add a help
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #44 from Kevin Funk ---
Git commit 86bad1f222716c9a204423f29080298b05713b2c by Kevin Funk.
Committed on 04/10/2018 at 21:42.
Pushed by kfunk into branch 'wip/windows-fixes'.
clang: Also detect Clang builtin dirs at runtime
M +5-1p
https://bugs.kde.org/show_bug.cgi?id=393779
Kevin Funk changed:
What|Removed |Added
Latest Commit||https://cgit.kde.org/kdevel
|
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #43 from Bernd Buschinski ---
Git commit 716372ae2e8dff9c51e94d33443536786e4bd85b by Bernd Buschinski.
Committed on 04/10/2018 at 18:36.
Pushed by buschinski into branch '5.3'.
Use CLANG_INCLUDE_DIRS for clang include dir
Summary:
Use CLAN
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #42 from Bernd Buschinski ---
https://phabricator.kde.org/D15895
hope this helps :)
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=393779
Bernd Buschinski changed:
What|Removed |Added
CC||b.buschin...@googlemail.com
--- Comment #41
https://bugs.kde.org/show_bug.cgi?id=393779
Michael Pyne changed:
What|Removed |Added
CC||mp...@kde.org
--- Comment #40 from Michael Pyne
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #39 from Eugene Shalygin
---
(In reply to Milian Wolff from comment #38)
> current master now uses cpuid.h, does this work on gentoo?
What should have changed?
kdevplatform.shell: Could not load plugin "kdevclangsupport" , it reported th
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #38 from Milian Wolff ---
current master now uses cpuid.h, does this work on gentoo?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #37 from Gleb Popov <6year...@gmail.com> ---
Here's the patch we are applying to our Clang package:
https://svnweb.freebsd.org/ports/head/devel/llvm60/files/clang/patch-tools_clang_lib_Headers_CMakeLists.txt?view=markup
So, using vadefs.h in
https://bugs.kde.org/show_bug.cgi?id=393779
Edward Kigwana changed:
What|Removed |Added
CC||edwardw...@gmail.com
--
You are receiving thi
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #36 from Eugene Shalygin
---
Gentoo does package the complete Clang package too.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #35 from Gleb Popov <6year...@gmail.com> ---
(In reply to Milian Wolff from comment #34)
> it was just a heuristic that worked well on my system :) do you have a
> better suggestion?
I've got an impression that this problem is specific to ge
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #34 from Milian Wolff ---
it was just a heuristic that worked well on my system :) do you have a better
suggestion?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=393779
arrowdodger <6year...@gmail.com> changed:
What|Removed |Added
CC||6year...@gmail.com
--- Commen
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #32 from Milian Wolff ---
Long-term fixing that in libclang itself would be ideal. For now, we need to
support older libclang and llvm-config anyways, so coming up with a heuristic
is required anyways.
We could also just say: We depend on c
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #31 from Sven Brauch ---
That sounds super terrible to me. Why exactly can there not be an option in
llvm-config which simply prints this path?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #30 from Eugene Shalygin
---
If it is possible to get libclang version at runtime, I would add a
configuration parameter to pass a regular expression that transforms the clang
version string into the includes directory path. I hope distribu
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #29 from Milian Wolff ---
right, we may need to implement heuristics similar to what the other tools out
there that use libclang do. cf.:
https://github.com/Rip-Rip/clang_complete/issues/238
--
You are receiving this mail because:
You are
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #28 from Eugene Shalygin
---
I'm unable to find a direct reference to the include directory within files,
that are installed as part of "libclangxxx" in other distributions. Only those
belonging to the clang package contain this path.
--
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #27 from Milian Wolff ---
OK, good! I was worried for a moment there :)
Now we just need to find a way to fix this for Gentoo... And do the lookup at
runtime...
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #26 from Eugene Shalygin
---
Thank you for the last commit! It greatly simplified testing for me.
It seems I made a mistake earlier, because now supplying only the clang include
path works, as you assured it has to. Here is the list of inc
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #25 from Milian Wolff ---
So, if you updated to current master, then please tell me what you get when you
run kdevelop like this:
CLEAR_DUCHAIN_DIR=1 KDEV_CLANG_BUILTIN_DIR=/usr/lib64/clang/6.0.0/include/
kdevelop
do you still see the erro
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #24 from Milian Wolff ---
Git commit 169371b5d3448949122d5846c7da29ab86b1a0e9 by Milian Wolff.
Committed on 04/05/2018 at 15:26.
Pushed by mwolff into branch 'master'.
Allow overriding the path to the builtin clang compiler headers
The cur
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #23 from Milian Wolff ---
Ah, that is indeed an important detail which was not clear at all from the
previous comments.
So to make sure:
You changed KDEV_CLANG_BUILTIN_DIR to /usr/lib64/clang/6.0.0/include/, then
recompiled and installed K
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #22 from Eugene Shalygin
---
(In reply to Eugene Shalygin from comment #21)
> problem, as reported in the comment #1.
In the comment #0 (description), of course.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #21 from Eugene Shalygin
---
(In reply to Milian Wolff from comment #20)
> Yes, I've read your comments. I don't understand why they are contradicting
> what I said?
Can't understand you, sorry. I wrote that if I put the correct path to t
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #20 from Milian Wolff ---
Yes, I've read your comments. I don't understand why they are contradicting
what I said? Clang knows the path to the compiler-builtins, and when you use
all of those then sure, the problems will vanish. But only bec
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #19 from Eugene Shalygin
---
... and /usr/lib is symlinked to /usr/lib64 on my system.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #18 from Eugene Shalygin
---
(In reply to Milian Wolff from comment #17)
> Yes, we have to use paths that fit to whatever libclang you are using. And
> libstdc++/libc++ is not important here. This is about the compiler builtin
> headers, su
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #17 from Milian Wolff ---
Yes, we have to use paths that fit to whatever libclang you are using. And
libstdc++/libc++ is not important here. This is about the compiler builtin
headers, such as these:
$ ls /usr/lib/clang/6.0.0/include/
adxin
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #16 from Eugene Shalygin
---
Do you mean that the paths have to be obtained from libclang?
GCC is involved simply because Clang is using its libstd++, and no matter what
version of it was used to build Clang itself, Clang uses directories
https://bugs.kde.org/show_bug.cgi?id=393779
Milian Wolff changed:
What|Removed |Added
Status|UNCONFIRMED |CONFIRMED
Ever confirmed|0
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #14 from Eugene Shalygin
---
The patch is invalid: the dirs have to be determined at run-time, because GCC
upgrade changes them.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=393779
Eugene Shalygin changed:
What|Removed |Added
Attachment #112387|0 |1
is obsolete|
https://bugs.kde.org/show_bug.cgi?id=393779
Eugene Shalygin changed:
What|Removed |Added
Attachment #112386|0 |1
is obsolete|
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #11 from Eugene Shalygin
---
Created attachment 112386
--> https://bugs.kde.org/attachment.cgi?id=112386&action=edit
Take all clang++ include paths
After adding all the include paths from clang++ -v output to Project
properties/Language
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #10 from Eugene Shalygin
---
Correcting the path in the config file does not solve the problem. It might be
important that my clang is installed without libcxx.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #9 from Eugene Shalygin ---
Gentoo packages allow parallel installation of several major LLVM/CLang
version, ad each one can be 64 bit or 32, or both in parallel.
Why don't you parse clang++ -v output to get the list of default include
dir
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #8 from Sven Brauch ---
Hm. On my system,
> llvm-config --includedir
/usr/include
and
> llvm-config --libdir
/usr/lib
Both is definitely not what we want to put here. I don't know why this returns
a path of a completely different kind on
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #7 from Eugene Shalygin ---
CLANG_LIBRARY_DIRS is "/usr/lib64/llvm/6/lib64" and this path is correct, as I
wrote above; the path is the same as returned by llvm-config --libdir.
--
You are receiving this mail because:
You are watching all
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #6 from Sven Brauch ---
What is the output of llvm-config --libdir? That is what is used by cmake to
find this directory as far as I can see.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #5 from Sven Brauch ---
... CLANG_LIBRARY_DIRS this was meant to read, of course
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=393779
Sven Brauch changed:
What|Removed |Added
CC||m...@svenbrauch.de
--- Comment #4 from Sven Brauc
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #3 from Eugene Shalygin ---
And the last piece:
$ clang++ -c file.cc -v
clang version 6.0.0 (tags/RELEASE_600/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm/6/bin
Selected GCC installation: /usr/lib/gcc/x8
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #2 from Eugene Shalygin ---
And yes, /usr/lib64/llvm/6/lib64 is the correct path for the clang libraries
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=393779
--- Comment #1 from Eugene Shalygin ---
#define KDEV_CLANG_BUILTIN_DIR "/usr/lib64/llvm/6/lib64/clang/6.0.0/include" in
the generated file; the path is wrong. FYI,
$ llvm-config --includedir
/usr/lib64/llvm/6/include
--
You are receiving this mail be
47 matches
Mail list logo