Cstddef 50 10 error stddef h file not found

This topic has been deleted. Only users with topic management privileges can see it.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Subject: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed
Package: qtcreator
Version: 4.11.0-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Install `qtcreator` but not the `libclang-common-8-dev` package
Note: Installing `clang` package will install `clang-9` and not `clang-8`.

When opening a CMake project in qtcreator that does `#include
<cstddef>`, an error is reported by the clang code model in `cstddef`:
`cstddef:50:10: fatal error: 'stddef.h' file not found`



   * What exactly did you do (or not do) that was effective (or
ineffective)?

When installing the `libclang-common-8-dev` package, the clang code
model error goes away and no error is reported anymore.


   * What outcome did you expect instead?

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).



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.8-amdnoflr-20200109 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qtcreator depends on:
ii  libc6                                  2.29-10
ii  libclang1-8                            1:8.0.1-7
ii  libgcc-s1 [libgcc1]                    10-20200222-1
ii  libgcc1                                1:10-20200222-1
ii  libkf5syntaxhighlighting5              5.62.0-3
ii  libllvm8                               1:8.0.1-7
ii  libqbscore1.13                         1.13.1-2
ii  libqt5concurrent5                      5.12.5+dfsg-8
ii  libqt5core5a [qtbase-abi-5-12-5]       5.12.5+dfsg-8
ii  libqt5designer5                        5.12.5-2+b2
ii  libqt5designercomponents5              5.12.5-2+b2
ii  libqt5gui5                             5.12.5+dfsg-8
ii  libqt5help5                            5.12.5-2+b2
ii  libqt5network5                         5.12.5+dfsg-8
ii  libqt5printsupport5                    5.12.5+dfsg-8
ii  libqt5qml5 [qtdeclarative-abi-5-12-5]  5.12.5-5
ii  libqt5quick5                           5.12.5-5
ii  libqt5quickwidgets5                    5.12.5-5
ii  libqt5script5                          5.12.5+dfsg-2
ii  libqt5serialport5                      5.12.5-1
ii  libqt5sql5                             5.12.5+dfsg-8
ii  libqt5sql5-sqlite                      5.12.5+dfsg-8
ii  libqt5widgets5                         5.12.5+dfsg-8
ii  libqt5xml5                             5.12.5+dfsg-8
ii  libstdc++6                             10-20200222-1
ii  qml-module-qtqml-models2               5.12.5-5
ii  qml-module-qtquick-controls            5.12.5-1+b1
ii  qml-module-qtquick2                    5.12.5-5
ii  qtchooser                              66-2
ii  qtcreator-data                         4.11.0-2

Versions of packages qtcreator recommends:
ii  clang                          1:9.0-49
ii  clang-tidy                     1:9.0-49
ii  gdb-minimal [gdb]              9.1-1
ii  konsole [x-terminal-emulator]  4:19.08.1-2+b1
ii  make                           4.2.1-1.2
pn  qmlscene                       <none>
pn  qt5-doc                        <none>
pn  qt5-qmltooling-plugins         <none>
pn  qtbase5-dev-tools              <none>
pn  qtcreator-doc                  <none>
pn  qtdeclarative5-dev-tools       <none>
pn  qttools5-dev-tools             <none>
pn  qttranslations5-l10n           <none>
pn  qtxmlpatterns5-dev-tools       <none>

Versions of packages qtcreator suggests:
pn  clazy       <none>
ii  cmake       3.16.3-1
ii  g++         4:9.2.1-3.1
ii  git         1:2.25.1-1
pn  kate-data   <none>
pn  subversion  <none>
ii  valgrind    1:3.15.0-1


Versions of libclang-common-8-dev that fix the issue:
libclang-common-8-dev  1:8.0.1-7

-- no debconf information

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F

[signature.asc (application/pgp-signature, attachment)]

Message #10 received at 952718-done@bugs.debian.org (full text, mbox, reply):

Hi Alexis!

On Thu, 27 Feb 2020 at 19:33, Alexis Murzeau <amubtdx@gmail.com> wrote:
>
> Subject: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed
> Package: qtcreator
> Version: 4.11.0-2
> Severity: normal
>
> Dear Maintainer,
>
>    * What led up to the situation?
>
> Install `qtcreator` but not the `libclang-common-8-dev` package
> Note: Installing `clang` package will install `clang-9` and not `clang-8`.
>
> When opening a CMake project in qtcreator that does `#include
> <cstddef>`, an error is reported by the clang code model in `cstddef`:
> `cstddef:50:10: fatal error: 'stddef.h' file not found`

That's just right, the header is not installed yet.

>    * What exactly did you do (or not do) that was effective (or
> ineffective)?
>
> When installing the `libclang-common-8-dev` package, the clang code
> model error goes away and no error is reported anymore.

Right, because that's one of the packages that provides stddef.h

>    * What outcome did you expect instead?
>
> 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`.

No, you ar emixing two things here.

The clang code model is a plugin that uses clang's API to parse a
source file and do checks over it, like missing headers. It does not
requires clang headers.

What you saw is a project that needed a header not available in the
system (or at least not for the selected toolchain). The same could
happen if for example you install qtcreator but not qbase5-dev, and
then you open a project that needs QString.

I'm so closing this bug. If you think I might be missing some detail
please feel free to reply to this bug and I'll reopen it if necessary
(or you can do so if you think you are sure about it).

Regards, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Message #15 received at 952718@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi,

On 28/02/2020 19:11, Lisandro Damián Nicanor Pérez Meyer wrote:
>>    * What outcome did you expect instead?
>>
>> 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`.
> 
> No, you ar emixing two things here.
> 
> The clang code model is a plugin that uses clang's API to parse a
> source file and do checks over it, like missing headers. It does not
> requires clang headers.> 
> What you saw is a project that needed a header not available in the
> system (or at least not for the selected toolchain). The same could
> happen if for example you install qtcreator but not qbase5-dev, and
> then you open a project that needs QString.

Actually, the error is about missing `stddef.h` header which should be available everywhere.
It happens with a simple program like this:
```
#include <stddef.h>

int main() {
	return 0;
}
```

Using another computer with outdated packages, I noticed that:

- When having qtcreator 4.10.2-2 and no `libclang-common-8-dev` package installed,
a project with the above file in `main.cpp` configured to be compiled using cmake and gcc-9,
the clang code model works fine, there is no highlighted errors.
When I do Ctrl+Click on the stddef.h header, qtcreator opens
/usr/lib/gcc/x86_64-linux-gnu/9/include/stddef.h

- After having upgraded qtcreator to 4.11.0-2, the code model now shows the error
about missing `stddef.h` for the same project and configuration (cmake + gcc-9).
When I do Ctrl+Click on the stddef.h header, despite being "not found", qtcreator opens the same file:
/usr/lib/gcc/x86_64-linux-gnu/9/include/stddef.h.

- If I downgrade qtcreator to 4.10.2-2 again, the error about `stddef.h` not found goes away.

I've attached a test project I used with gcc-9 compiler.

> 
> I'm so closing this bug. If you think I might be missing some detail
> please feel free to reply to this bug and I'll reopen it if necessary
> (or you can do so if you think you are sure about it).
> 
> Regards, Lisandro.
> 

I searched on QtCreator's own bug tracker and found a matching issue:
https://bugreports.qt.io/browse/QTCREATORBUG-23451

I will reopen this bug as it is definitely a regression in qtcreator 4.11 and
set the upstream url.


-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F

[test_stddef.zip (application/zip, attachment)]

[signature.asc (application/pgp-signature, attachment)]

Message #24 received at 952718@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

reopen 952718
forwarded 952718 https://bugreports.qt.io/browse/QTCREATORBUG-23451
tag 952718 upstream
thanks



El vie., 28 feb. 2020 19:35, Alexis Murzeau <amubtdx@gmail.com> escribió:

> Hi,
>
> On 28/02/2020 19:11, Lisandro Damián Nicanor Pérez Meyer wrote:
> >>    * What outcome did you expect instead?
> >>
> >> 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`.
> >
> > No, you ar emixing two things here.
> >
> > The clang code model is a plugin that uses clang's API to parse a
> > source file and do checks over it, like missing headers. It does not
> > requires clang headers.>
> > What you saw is a project that needed a header not available in the
> > system (or at least not for the selected toolchain). The same could
> > happen if for example you install qtcreator but not qbase5-dev, and
> > then you open a project that needs QString.
>
> Actually, the error is about missing `stddef.h` header which should be
> available everywhere.
> It happens with a simple program like this:
> ```
> #include <stddef.h>
>
> int main() {
>         return 0;
> }
> ```
>
> Using another computer with outdated packages, I noticed that:
>
> - When having qtcreator 4.10.2-2 and no `libclang-common-8-dev` package
> installed,
> a project with the above file in `main.cpp` configured to be compiled
> using cmake and gcc-9,
> the clang code model works fine, there is no highlighted errors.
> When I do Ctrl+Click on the stddef.h header, qtcreator opens
> /usr/lib/gcc/x86_64-linux-gnu/9/include/stddef.h
>
> - After having upgraded qtcreator to 4.11.0-2, the code model now shows
> the error
> about missing `stddef.h` for the same project and configuration (cmake +
> gcc-9).
> When I do Ctrl+Click on the stddef.h header, despite being "not found",
> qtcreator opens the same file:
> /usr/lib/gcc/x86_64-linux-gnu/9/include/stddef.h.
>
> - If I downgrade qtcreator to 4.10.2-2 again, the error about `stddef.h`
> not found goes away.
>
> I've attached a test project I used with gcc-9 compiler.
>

Great! Reopening and tagging accordingly.

Thanks a lot for the follow up!

>

[Message part 2 (text/html, inline)]

Message #31 received at 952718@bugs.debian.org (full text, mbox, reply):

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.

Message #40 received at 952718@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

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
<stddef.h>" 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 <stddef.h>" 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 (application/pgp-signature, attachment)]

Message #45 received at 952718@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi!

El mié., 4 mar. 2020 18:11, Alexis Murzeau <amubtdx@gmail.com> 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.

>

[Message part 2 (text/html, inline)]

Message #50 received at 952718@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

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 <amubtdx@gmail.com> 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 (application/pgp-signature, attachment)]

Message #55 received at 952718@bugs.debian.org (full text, mbox, reply):

Hi again.

On Wed, 4 Mar 2020 at 19:45, Alexis Murzeau <amubtdx@gmail.com> 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 <amubtdx@gmail.com> 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/

Message #60 received at 952718@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

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 (application/pgp-signature, inline)]

Message #65 received at 952718@bugs.debian.org (full text, mbox, reply):

Hi!

On Wed, 4 Mar 2020 at 20:40, Nicholas D Steeves <nsteeves@gmail.com> 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/

Message #70 received at 952718@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

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 <amubtdx@gmail.com> 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 <amubtdx@gmail.com> 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 (application/pgp-signature, attachment)]

Message #75 received at 952718@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi Lisandro,

Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com> writes:

> Hi!
>
> On Wed, 4 Mar 2020 at 20:40, Nicholas D Steeves <nsteeves@gmail.com> 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 <amubtdx@gmail.com> 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 (application/pgp-signature, inline)]

Message #82 received at 952718@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi,

Le 05/03/2020 à 01:12, Nicholas D Steeves a écrit :
> Hi Lisandro,
> 
> Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com> writes:
> 
>> Hi!
>>
>> On Wed, 4 Mar 2020 at 20:40, Nicholas D Steeves <nsteeves@gmail.com> 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
> [...]>
> 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?
> 


When the recommends on clang was added, the changelog got this:
```
 * Make qtcreator recommend clang, as it has added quite interesting tools
    that use it.

```

So I think the recommends is just a way so the user has recommended
tools available to qtcreator the same way `make` is recommended to build
a C/C++ project.

This is only a recommendation as the user may not want to use clang
stuff and just use, say, gcc and ninja instead for example.


I still think there should be a Depends (not Recommends) on
libclang-common-8-dev instead somewhere. (that is, directly from
qtcreator or indirectly)

This to ensure the clang code model of QtCreator (and perhaps other IDEs
that use it) works correctly and find its *builtin headers*.

Again, I emphasis on builtin headers as I do not talk about API headers
here; libclang's API headers are in a different package: libclang-8-dev.
See also my previous mail:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952718#70

@Lisandro, what do you think now given we were not talking about the
same headers before ?

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F

[signature.asc (application/pgp-signature, attachment)]

Message #87 received at 952718@bugs.debian.org (full text, mbox, reply):

Le 14/03/2020 à 12:45, Alexis Murzeau a écrit :
> 
> I still think there should be a Depends (not Recommends) on
> libclang-common-8-dev instead somewhere. (that is, directly from
> qtcreator or indirectly)
What is wrong with this solution?

Sorry if I missed a potential answer for this question.

S

Message #92 received at 952718@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Le 14/03/2020 à 12:54, Sylvestre Ledru a écrit :
> Le 14/03/2020 à 12:45, Alexis Murzeau a écrit :
>>
>> I still think there should be a Depends (not Recommends) on
>> libclang-common-8-dev instead somewhere. (that is, directly from
>> qtcreator or indirectly)
> What is wrong with this solution?
> 
> Sorry if I missed a potential answer for this question.
> 
> S

QtCreator's code model uses libclang-8.
If libclang-common-8-dev is not installed, QtCreator's code model won't
find some includes like <stddef.h> and highlight many false positive
errors in its editor.
This makes QtCreator's code model not fully working if
libclang-common-8-dev is not installed (that's why I would expect a
Depends instead of Recommends).

Installing the full clang-8 toolchain is overkill to me as only
libclang-common-8-dev is really needed to make the code model work fine,
and libclang-common-8-dev is rather small compared to the full clang
compiler.

I think the current clang Recommends is for the static analyzer given
this upstream commit bundling clang.exe for Windows:
https://github.com/qt-creator/qt-creator/commit/d02e80b87bc423f0ccb696c1b10378a74758a432
"Deploy clang binary for use by static analyzer"


-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F

[signature.asc (application/pgp-signature, attachment)]

Message #97 received at 952718@bugs.debian.org (full text, mbox, reply):

Hi!

I have discussed this with KDevelop's maintainer.

As Alexis states the code parser will not work with c++ projects if
the clang headers are not there. On the other hand if the c++ project
is using gcc instead of clang to build the wrong headers would be
displayed (even if the headers are meant to track gcc's ones, they are
still not the originals).

Following the same criterion as for another dependencies: Qt Creator
is not *just* a C++ IDE, so anyone wanting to add the relevant headers
should either install Recommends by default or proceed to install them
by hand.

Ideally we should be able to depend upon the same clang/llvm version
qtcreator was built with, without having to resort to regular
expressions or alike to modify debian/control on each upload. I have
not checked if this is doable yet, but will try to do it.

I expect the fix to be present in the next Qt Creator version I'll be
pushing to unstable, for which I do not have an ETA due to lack of
time.

Kinds regards, Lisandro.

Message #102 received at 952718@bugs.debian.org (full text, mbox, reply):

Package: qtcreator
Version: 4.11.0-2
Followup-For: Bug #952718

i just wasted about half an hour on researching this, so i'll summarize 
my current understanding:

libclang-N needs to depend on libclang-common-N-dev, as otherwise it's 
dysfunctional.

failing that, qtcreator needs to recommend libclang-common-N-dev. this 
could be upgraded to depends if the clang-related plugins incl.  
libclangsupport are factored out to a separate qtcreator sub-package 
which qtcreator recommends.
alternatively, this approach could be used to isolate the libclang-N 
dependency itself.

that qtcreator's code model technically uses the wrong headers is 
correct, but orthogonal to the issue, and usually not problematic (which 
is why the approach was deemed accepatable in the first place).

Message #107 received at 952718@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi! Just for the record, I haven't went ahead with this because I'm still
very time constrained, covid-19 is not precisely helping with that.

[Message part 2 (text/html, inline)]

Message #112 received at 952718@bugs.debian.org (full text, mbox, reply):

On 2020-04-04 2:20 p.m., Lisandro Damián Nicanor Pérez Meyer wrote:
> Hi! Just for the record, I haven't went ahead with this because I'm still very time constrained,
> covid-19 is not precisely helping with that.

Maybe a good idea here would be to split off the clang code model plugin into a seperate package so
that these dependencies can be tracked a little more easily without putting all the dependencies
onto the one master package. There are lots of people that would be using Qt Creator without the
need for clang code model, for example. Would this be something worth considering?

- Adam

Message #117 received at 952718@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi!

El sáb., 4 abr. 2020 12:22, Adam Majer <adamm@zombino.com> escribió:

> On 2020-04-04 2:20 p.m., Lisandro Damián Nicanor Pérez Meyer wrote:
> > Hi! Just for the record, I haven't went ahead with this because I'm
> still very time constrained,
> > covid-19 is not precisely helping with that.
>
> Maybe a good idea here would be to split off the clang code model plugin
> into a seperate package so
> that these dependencies can be tracked a little more easily without
> putting all the dependencies
> onto the one master package. There are lots of people that would be using
> Qt Creator without the
> need for clang code model, for example. Would this be something worth
> considering?
>

I don't think it will make the packaging easier, but if people find a
separate package useful then I'm all for it.

>

[Message part 2 (text/html, inline)]

Message #124 received at 952718-close@bugs.debian.org (full text, mbox, reply):

Source: qtcreator
Source-Version: 4.12.4-1
Done: Pino Toscano <pino@debian.org>

We believe that the bug you reported is fixed in the latest version of
qtcreator, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 952718@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Pino Toscano <pino@debian.org> (supplier of updated qtcreator package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Wed, 19 Aug 2020 19:00:23 +0200
Source: qtcreator
Architecture: source
Version: 4.12.4-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Qt/KDE Maintainers <debian-qt-kde@lists.debian.org>
Changed-By: Pino Toscano <pino@debian.org>
Closes: 919860 952718 966007 966169
Changes:
 qtcreator (4.12.4-1) unstable; urgency=medium
 .
   * Team upload.
   * New upstream release.
   * Use the default LLVM/clang Debian versions, rather than hardcoding 8.
     Hopefully qtcreator will properly support newer LLVM versions fast enough.
     (Closes: #966007)
     - switch the libclang-8-dev build dependency to libclang-dev >= 8
     - switch the llvm-8-dev build dependency to llvm-dev >= 8
     - get the LLVM root using llvm-config
   * Switch the generic clang recommend to a dependency of the exact clang-N
     used to build (Closes: #919860, #952718) (LP: #1890434, #1877927)
     - add the clang build dependency to get the used clang executable
   * Drop the Debian man page, as it is outdated, and it offers no useful
     information.
   * Force the version of libqt5designercomponents5 as dependency to be at least
     the same as used during the build. (Closes: #966169)
   * Remove the kate-data suggest, as it does not exist anymore; syntax
     highlighting files are already provided by KF5SyntaxHighlighting.
Checksums-Sha1:
 b64d28cf04c425add5db926b4cb35a3bea450091 2880 qtcreator_4.12.4-1.dsc
 6ae0934654c8dc0065b2104e6a43e8ef72f8bda3 34347508 qtcreator_4.12.4.orig.tar.xz
 2eb9c91914b5dcb28ae1c36dfdb58ff159d77f2f 27440 qtcreator_4.12.4-1.debian.tar.xz
 2b2402bc4fdeb6cb27fa02d3e4bbaba2e7b91080 13786 qtcreator_4.12.4-1_source.buildinfo
Checksums-Sha256:
 d162b21f15d8c6eb56c4465f2c599ac7c7bf639d1d29820189c90ca0ba4ee412 2880 qtcreator_4.12.4-1.dsc
 3f47d83344476b172f0c51a2351f5a9d8ce8dd8dd2eea827a52276763471b97a 34347508 qtcreator_4.12.4.orig.tar.xz
 a38fb9c04c9522514f83bf5042d8a4a16174f0b82ca97c7d7e6e714ef089e82c 27440 qtcreator_4.12.4-1.debian.tar.xz
 062bd505acd39d6ce55cfa3b98d53f34392084a59b7d29ba018036649c405d34 13786 qtcreator_4.12.4-1_source.buildinfo
Files:
 7257d6c32c8d8b700a0ea4c97b985f1a 2880 devel optional qtcreator_4.12.4-1.dsc
 5b539c03bdf807866e2383d7180871dc 34347508 devel optional qtcreator_4.12.4.orig.tar.xz
 e2c106e162ed668632c68948d551aa7f 27440 devel optional qtcreator_4.12.4-1.debian.tar.xz
 657eb4372e5ae69fbf3d0713dad37d50 13786 devel optional qtcreator_4.12.4-1_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEXyqfuC+mweEHcAcHLRkciEOxP00FAl89WuMACgkQLRkciEOx
P00SmA/+L7Ej10Hp1BQNMY1362/EltcSq8Hj0WNpws57GNujbkDfjJWCGq65zqIe
3pCfKiGm55OBawWJqOMKFPAtUbjQwBgr9zTb6Jn8Y7WugIfFDYszzzpg2PwNFonL
ISg0i8lyigKVaBLnHdi6w/QtsC0mmWgQMFPmk/zMOE5jjw4dn0cyy/YYdpEPZWV9
HV6y6hx4SlXPiIBcr2UDJAryobpElA1sUSjax2O0Ny5c1yMXvuY3vUNM/z/CB7Zi
/jJOGAFz9ETbSfF05c4PfDiTx/AJgc4850dWDKjCatkdF+euhVWHQaW4LE/x/+5/
yYYYKojkYPu/m7Hhef85TNCO0RKMKRzJ2JzE9gS+RkvzQ7yQuR4jVMxR4zZyBxgi
keUAvAbTxU903mW76zx1l7+1sgLKvEztGbAN8zT6hBZNEu5jbSlZpE3zxzJkDZcn
rYFs6YN0L4/BOVbAaAB9ZbQZu8f+Z6vbrCK0iciKtcj1uBXl66PFmzVjBZEqI6ec
p3BEH/9cQ9P838ozG8EJtY717DGQzsrozoYlX6Z1Kxua1utMPQ+jyqnXkCKzQk0w
RvbOotM07U6QefXNIMUYG7gKaHbeXL7eX3ol/FcwPntPLgDSxEAI5tdjTaXsU491
RO0oL+4EKpBTzOspOD8WLRoejzIajHzidbv8VGDR+JpEbh5hn0A=
=k4SO
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.