Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed
Hi Lisandro, Lisandro Damián Nicanor Pérez Meyer writes: > Hi! > > On Wed, 4 Mar 2020 at 20:40, Nicholas D Steeves wrote: >> >> Hi Lisandro, >> >> Out of curiosity, could this be solved for a Debian (and derivatives) >> context by changing the Recommends on clang and clang-tidy to their >> versioned package names (eg: clang-8 and clang-tidy-8)? > > No, this is not a versioning problem. > I agree, ideally it should be solved upstream, but a side-effect of installing Recommends s/clang/clang-8/ is that it pulls in a dependency on libclang-common-8-dev, and Alexis Murzeau writes: > Install `qtcreator` but not the `libclang-common-8-dev` package > Note: Installing `clang` package will install `clang-9` and not `clang-8`. > [snip] > > When installing the `libclang-common-8-dev` package, the clang code > model error goes away and no error is reported anymore. > [snip] > > I expect the clang code model to work out of the box with all depends > and recommends dependencies of `qtcreator`. > As of now, `libclang-common-8-dev` seems required by the clang code > model to work correctly, but that package is not a direct or indirect > dependency of `qtcreator`. > > The simplest solution (if it is the right one) is to add > `libclang-common-8-dev` as depends or recommends dependency to qtcreator. > Or maybe it should be a dependency of `libclang1-8` instead (which > qtcreator depends on). > My proposal would solve the Debian (and derivatives) case and is easy to update/maintain with a sed regex. Is our team categorically opposed to working around upstream issues using Debian packaging facilities? Thanks, Nicholas signature.asc Description: PGP signature
Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed
Le 05/03/2020 à 00:03, Lisandro Damián Nicanor Pérez Meyer a écrit : > Hi again. > > On Wed, 4 Mar 2020 at 19:45, Alexis Murzeau wrote: >> >> Le 04/03/2020 à 22:46, Lisandro Damián Nicanor Pérez Meyer a écrit : >>> Hi! >>> >>> El mié., 4 mar. 2020 18:11, Alexis Murzeau escribió: >>> Hi, I've a question about whether libclang1-X should depend on libclang-common-X-dev to always have the clang's builtin headers available when libclang is installed. >>> >>> Definitely not. Headers should depend upon the library, not the other way >>> around. >>> >>> >> >> Why do you think that ? > > Because development files should depend upon the libraries they > provide the headers for, not the other way around. It's the basics of > library packaging. libclang-common-X-dev contains clang's builtin headers which are not the same as libclang API headers. clang's builtin headers are not the ones providing the API of libclang but compiler builtin functions like _mm_sqrt_ps using clang's specific functions like __builtin_ia32_sqrtps. The package that contains libclang's API headers is libclang-X-dev, not libclang-common-X-dev. So to sum up, clang has: - libclang-X-dev: libclang's API headers containing functions available in libclang to manipulate AST, compile code, ... (for example ASTMutationListener.h, CompilerInstance.h, CXCompilationDatabase.h, ...) - libc++-X-dev: clang's libc++ standard library headers (for example vector, unordered_map, ...) - libc6-dev: GNU C standard library headers (for example stdlib.h, stdio.h, ...) - libclang-common-X-dev: clang's builtin headers (for example, immintrin.h, stddef.h, x86intrin.h, ...) And there is also libllvm API headers: - libllvm-X-dev: llvm's API headers (for example IRReader.h, LinkTimeOptimizer.h, ...) > > [snip] >> If libclang1-X should not depend on libclang-common-X-dev, then users of >> libclang1-X (like QtCreator, kdevelop, ...) that use libclang to compile >> code from source should depend themselves on libclang-common-X-dev as it >> is required for them to work correctly. > > And then again, wrong. Making an IDE show the header a compiler is > **NOT** using it's plain **WRONG**. I already expressed that in the > bug upstream and in Qt Creator's bug. Note that I did even stress the > question in upstream's bug just to show that nobody could say > otherwise. Neither Marko nor Thiago denied that. This may be wrong, but having parse errors because of issues like "fatal error: 'stddef.h' file not found" is not better. It makes qtcreator's code model to fail to parse code, which is one of the key feature of an IDE like this. It's better have the IDE use clang's builtin headers than not being able to parse code because of missing builtin headers. > > So if you want a fix make clang understand other compiler's headers, > or provide a better code parser. Currently, whatever if this is right or wrong, the only way to fix "fatal error: 'stddef.h' file not found" when using qtcreator or kdevelop on Debian is to install the appropriate libclang-common-X-dev. The toolchain used to parse the code model for qtcreator and the toolchain used to actually compile the code can be different, but that doesn't matter because clang already provide the appropriate *builtin* headers to make other compilers specific functions also available with clang. For example, gcc provides the non standard function _get_ssp available from immintrin.h [0], clang also does provide it in cetintrin.h builtin header which is included by its own immintrin.h builtin header. MSVC provides _InterlockedCompareExchange_HLEAcquire function (which is specific to MSVC as said in [1]), clang also provides it in the same immintrin.h builtin header (even on linux, these builtin headers are in libclang-common-X-dev package. Or maybe guarded with some #ifdef). So while clang support other compilers specifics, it still needs to have its matching *builtin* headers (which are mostly only intrinsics or platform specific stuff) as builtin headers of each compilers are probably highly specific to the compiler they are made for (which are different from API headers or C and C++ standard library headers). > > Regards, Lisandro. > > [0] https://gcc.gnu.org/onlinedocs/gcc/x86-control-flow-protection-intrinsics.html#x86-control-flow-protection-intrinsics [1] https://docs.microsoft.com/fr-fr/cpp/intrinsics/interlockedcompareexchange-intrinsic-functions?view=vs-2019 -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed
Hi! On Wed, 4 Mar 2020 at 20:40, Nicholas D Steeves wrote: > > Hi Lisandro, > > Out of curiosity, could this be solved for a Debian (and derivatives) > context by changing the Recommends on clang and clang-tidy to their > versioned package names (eg: clang-8 and clang-tidy-8)? No, this is not a versioning problem. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed
Hi Lisandro, Out of curiosity, could this be solved for a Debian (and derivatives) context by changing the Recommends on clang and clang-tidy to their versioned package names (eg: clang-8 and clang-tidy-8)? Cheers, Nicholas signature.asc Description: PGP signature
Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed
Hi again. On Wed, 4 Mar 2020 at 19:45, Alexis Murzeau wrote: > > Le 04/03/2020 à 22:46, Lisandro Damián Nicanor Pérez Meyer a écrit : > > Hi! > > > > El mié., 4 mar. 2020 18:11, Alexis Murzeau escribió: > > > >> Hi, > >> > >> I've a question about whether libclang1-X should depend on > >> libclang-common-X-dev to always have the clang's builtin headers > >> available when libclang is installed. > >> > > > > Definitely not. Headers should depend upon the library, not the other way > > around. > > > >> > > > > Why do you think that ? Because development files should depend upon the libraries they provide the headers for, not the other way around. It's the basics of library packaging. [snip] > If libclang1-X should not depend on libclang-common-X-dev, then users of > libclang1-X (like QtCreator, kdevelop, ...) that use libclang to compile > code from source should depend themselves on libclang-common-X-dev as it > is required for them to work correctly. And then again, wrong. Making an IDE show the header a compiler is **NOT** using it's plain **WRONG**. I already expressed that in the bug upstream and in Qt Creator's bug. Note that I did even stress the question in upstream's bug just to show that nobody could say otherwise. Neither Marko nor Thiago denied that. So if you want a fix make clang understand other compiler's headers, or provide a better code parser. Regards, Lisandro. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed
Le 04/03/2020 à 22:46, Lisandro Damián Nicanor Pérez Meyer a écrit :
> Hi!
>
> El mié., 4 mar. 2020 18:11, Alexis Murzeau escribió:
>
>> Hi,
>>
>> I've a question about whether libclang1-X should depend on
>> libclang-common-X-dev to always have the clang's builtin headers
>> available when libclang is installed.
>>
>
> Definitely not. Headers should depend upon the library, not the other way
> around.
>
>>
>
Why do you think that ?
My view on this is that libclang contains the compiler and the compiler
needs the headers but the headers don't really need the compiler to be used.
I agree that if you install the headers, you probably have to install
clang to use them anyway.
But actually, clang binaries (like clang-tidy) depends on
libclang-common-X-dev which depends on libllvm (that one is different
than libclang. libllvm is the backend of the compiler while libclang and
clang are the frontend)
So as of now, headers do not depends on libclang or clang, and clang
depends on these headers but not libclang.
clang also depends on libclang, as do QtCreator and kdevelop and other
IDE using libclang.
That's why I'm wondering if the dependency of clang-X =>
libclang-common-X-dev should be lifted to libclang1-X =>
libclang-common-X-dev.
For clang, this would start from:
clang-8 =>
libclang1-8
libclang-common-8-dev
to:
clang-8 =>
libclang1-8 =>
libclang-common-8-dev
The description of libclang1-X is:
The C Interface to Clang provides a relatively small API that exposes
facilities for:
- parsing source code into an abstract syntax tree (AST),
- loading already-parsed ASTs,
- traversing the AST,
- associating physical source locations with elements within the AST,
- and other facilities that support Clang-based development tools.
Some of them (like the one using already parsed AST) might not need
builtin headers, so it might be understandable to avoid a dependency
from libclang1 to libclang-common-X-dev.
binary rdepends on libclang1-{6.0,7,8} are:
- doxygen
- clang-X which also depends already on libclang-common-X-dev
- clang-tools-X which also depends on clang
- libclang-X-dev which also depends already on libclang-common-X-dev
- bpftrace (high-level tracing language for Linux eBPF)
- codelite (IDE for C, C++ and others)
- gnat-ps (IDE for C and Ada)
- gnome-builder which also depends on clang (IDE for C, C++ and others)
- irony-server (Emacs C/C++ minor mode)
- kdevelop which recommends clang (C/C++ IDE)
- libclang-perl (libclang perl bindings)
- qdoc-qt5 (tool to generate doc from C/C++ source files)
- qtcreator which recommends clang (C/C++ IDE)
- rtags which recommends libclang-common-X-dev (C/C++ client/server
indexer with integration for Emacs)
- shiboken2 (CPython bindings generator for C++ libraries)
- ycmd which recommends libclang-common-X-dev (code-completion &
comprehension server)
So many of them uses libclang to parse C/C++ code, but only bpftrace do
not I think (it parses the BPFTrace language instead which is based on C).
If libclang1-X should not depend on libclang-common-X-dev, then users of
libclang1-X (like QtCreator, kdevelop, ...) that use libclang to compile
code from source should depend themselves on libclang-common-X-dev as it
is required for them to work correctly.
--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
signature.asc
Description: OpenPGP digital signature
Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed
Hi! El mié., 4 mar. 2020 18:11, Alexis Murzeau escribió: > Hi, > > I've a question about whether libclang1-X should depend on > libclang-common-X-dev to always have the clang's builtin headers > available when libclang is installed. > Definitely not. Headers should depend upon the library, not the other way around. >
Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed
Hi, I've a question about whether libclang1-X should depend on libclang-common-X-dev to always have the clang's builtin headers available when libclang is installed. A bit of context: QtCreator uses libclang for its code model. If clang's builtin headers are not available in the system, libclang will fail to find its builtin headers (like stddef.h) and might fail to parse code and flag "#include " as an error because the header cannot be found (stddef.h is one of the builtin headers). This was reported to QtCreator's upstream in [2]. As seen in [0] and [1], libclang expect to have its builtin headers available to work correctly. While analyzing this bug, I found that kdevelop has the exact same issue as QtCreator. That is, if they are installed without the libclang's builtin headers, they both fail to parse "#include " as libclang can't find it. Codelite is probably in the same case as it uses libclang too but I've not tested it. So, I'm thinking that libclang1-X should have a dependency on libclang-common-X-dev as it seems all users of libclang will likely need the builtin headers too. (For example, libclang1-8 should depend on libclang-common-8-dev). @LLVM Packaging Tream, what do you think about adding this dependency ? Thanks :) [0] http://lists.llvm.org/pipermail/cfe-dev/2018-April/057688.html [1] http://clang.llvm.org/docs/LibTooling.html#builtin-includes [2] https://bugreports.qt.io/browse/QTCREATORBUG-23451 -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Processed: Limitation in clang's code
Processing commands for cont...@bugs.debian.org: > tag 952718 wontfix Bug #952718 [qtcreator] qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed Added tag(s) wontfix. > severity 952718 wishlist Bug #952718 [qtcreator] qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed Severity set to 'wishlist' from 'normal' > thanks Stopping processing here. Please contact me if you need assistance. -- 952718: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952718 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#952718: Limitation in clang's code
tag 952718 wontfix severity 952718 wishlist thanks Hi! According to the upstream bug this is a limitaion of using clang for the code model, as it can't parse gcc's headers. Forcing a dependency on clang headers means that Creator would be showing a different header than the one really used at compile time. This is problematic, as they might differ. As an example I use Creator for microcontrollers which might have very different definitions. It's not up to the package maintainers to tape over upstream limitations/bugs, and showing by default a wrong header is definitely not the right solution. I am so lowering the severity to wishlist and marking it as wontfix, as upstream does not seems to have plans to solve this issue, which is totally understandable.
Bug#953088: powerdevil: suspend function does not put CPU into sleep
Package: powerdevil Version: 4:5.17.5-2 Severity: normal Dear Maintainer, After installation of plasma 5.17.5 the suspend function from the kmenu does not put the CPU into sleep anymore. The system goes to a black screen and stays there. You are able to 'wake up' the systeem by keyboard or mouse interrupt, but after that the system does not fully recover/ restarts all services (eg. akonadi databse connection is lost) I am able to reproduce this. Did not see anything suspicious in .xsession-errors. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (700, 'experimental'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), LANGUAGE=nl_BE:nl (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages powerdevil depends on: ii kio 5.62.1-2+b1 ii libc62.29-10 ii libkf5activities55.62.0-1+b2 ii libkf5authcore5 5.62.0-1+b1 ii libkf5completion55.62.0-1+b1 ii libkf5configcore55.62.0-1+b1 ii libkf5configgui5 5.62.0-1+b1 ii libkf5configwidgets5 5.62.0-1+b1 ii libkf5coreaddons55.62.0-1 ii libkf5crash5 5.62.0-1+b1 ii libkf5dbusaddons55.62.0-1 ii libkf5globalaccel-bin5.62.0-1+b1 ii libkf5globalaccel5 5.62.0-1+b1 ii libkf5i18n5 5.62.0-1 ii libkf5kiowidgets55.62.1-2+b1 ii libkf5networkmanagerqt6 5.62.0-1 ii libkf5notifyconfig5 5.62.0-1+b1 ii libkf5service-bin5.62.0-1 ii libkf5service5 5.62.0-1 ii libkf5solid5 5.62.0-2 ii libkf5waylandclient5 4:5.62.0-2+b1 ii libkf5widgetsaddons5 5.62.0-1+b1 ii libkf5xmlgui55.62.0-1+b1 ii libkworkspace5-5 4:5.17.5-4 ii libpowerdevilcore2 4:5.17.5-2 ii libpowerdevilui5 4:5.17.5-2 ii libqt5core5a 5.12.5+dfsg-8 ii libqt5dbus5 5.12.5+dfsg-8 ii libqt5gui5 5.12.5+dfsg-8 ii libqt5widgets5 5.12.5+dfsg-8 ii libqt5x11extras5 5.12.5-1 ii libstdc++6 10-20200222-1 ii libudev1 244.3-1 ii libxcb-dpms0 1.13.1-5 ii libxcb-randr01.13.1-5 ii libxcb1 1.13.1-5 ii powerdevil-data 4:5.17.5-2 powerdevil recommends no packages. powerdevil suggests no packages. -- no debconf information
