Bug 1832695

I'm having what I'm sure is the same issue with the current F32 clazy-1.6-3.fc32.x86_64, and it seems to have to do with the include path clazy is using.

In my case, I'm building a CMake project which can be compiled successfully with either g++ or clang++, but when I try to use the recommended `cmake -DCMAKE_CXX_COMPILER=clang ...` CMake fails to even configure the build tree, claiming that clazy "can't compile a simple test program".

So after giving up there, I configured the CMake project to build with clang++ and export its compile commands for clazy-standalone consumption:

pushd build
cmake -DCMAKE_CXX_COMPILER=/usr/bin/clang++ -DCMAKE_C_COMPILER=/usr/bin/clang -DCMAKE_EXPORT_COMPILE_COMMANDS=1 ..
popd
CLANGXX=/usr/bin/clang++ clazy-standalone -p build/compile_commands.json src/sourcefile.cpp
In file included from .../src/sourcefile.cpp:31:
In file included from .../include/sourcefile.h:34:
In file included from /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/memory:64:
In file included from /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/bits/allocator.h:46:
In file included from /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/x86_64-redhat-linux/bits/c++allocator.h:33:
In file included from /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/ext/new_allocator.h:33:
In file included from /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/new:41:
In file included from /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/exception:147:
In file included from /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/bits/exception_ptr.h:38:
/usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/bits/cxxabi_init_exception.h:38:10: fatal error: 'stddef.h' file not found
#include <stddef.h>
         ^~~~~~~~~~
1 error generated.
Error while processing .../src/sourcefile.cpp.

It strikes me as EXTREMELY odd that code building with a Clang-based tool would be referencing the GCC headers in /usr/bin/../lib/gcc/x86_64-redhat-linux/10/, even indirectly. But I see a similar path in the output Cajus posted:

1.      /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/type_traits:34:2: current parser token 'if'

*sigh* This:

when I try to use the recommended `cmake -DCMAKE_CXX_COMPILER=clang ...`

should of course have read:

when I try to use the recommended `cmake -DCMAKE_CXX_COMPILER=clazy ...`

So, after building my own clazy from https://github.com/KDE/clazy and installing it to /home/ferd/, then UNINSTALLING the system clazy package, I was able to get CMake to use /home/ferd/bin/clazy as the CMAKE_CXX_COMPILER and it appears to be functioning properly.

One thing I notice is that clazy-1.6-3.fc32.x86_64 is linked against LLVM 9, and some strace output when I was debugging this /seemed/ like it was really expecting to be running clang++ 9 as a result. Among other things, there were /usr/lib64/clang/9* paths it was trying to search. But those don't exist anymore, on an F32 install with clang-10.0.0-2.fc32.x86_64.

Perhaps the issue is that the F32 clang++ has been upgraded to Clang 10 / LLVM 10?

The clazy I built was, of course, compiled with clang++ (aka clang++-10). As a result, my ClazyPlugin.so is linked with libLLVM-10.so. (I uninstalled llvm9.0-libs along with clazy.)

This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

I think this can probably be closed, right Cajus? Fedora 33 clazy is linked with libLLVM-11.so, same version that's used by the current clang++-11 compiler binary. As a result, clazy seems to work fine in F33, and presumably (hopefully!) will continue to work correctly in F34.

F34 has clang 12 by default. I didn't change my CI Docker file (which compiles the latest and greatest clazy itself), so I didn't notice whether it works now or not.

Just gave it a shot, and - no - it's still impossible to build the project with the F34 provided clazy. It works fine with a self compiled one (or i.e. with the one extracted from the https://downloads.kdab.com/clazy/1.8/ AppImg).

Additionally clazy in F34 could be updated to 1.9 instead of 1.7.x.

https://fedora.pkgs.org/34/fedora-x86_64/clazy-1.7-3.fc34.x86_64.rpm.html

Mmm, I see that F34 clazy is still linked with LLVM 11, but as you say clang has been updated to version 12 so they're once again incompatible. That's a strange choice, especially when everything was working in F33.

I'm putting together a set of specfile changes to build clazy against LLVM-12, which I'll submit as PRs against both the rawhide and f34 branches at https://src.fedoraproject.org/rpms/clazy/ — hopefully we can get clazy updated to again be functional in F34.

I'm surprised, though, that there don't seem to be either an rpm-macros-llvm or rpm-macros-clang package that could be pulled in to make the clazy package depend on the _specific_ version of LLVM that matches the system's default clang... because clazy builds are most definitely tied to a specific clang version, and should be rebuilt as chained dependencies whenever clang gets updated. The versioned dependencies that would signal that in the package metadata don't seem to be present, currently, which is I think why clazy keeps falling out of step with the system clang.

I'll ask around on the packaging list, see if there's any interest in publishing a set of rpm-macros-clang / rpm-macros-llvm for situations like this.

(In reply to "FeRD" (Frank Dana) from comment #8)
>
> I'll ask around on the packaging list, see if there's any interest in
> publishing a set of rpm-macros-clang / rpm-macros-llvm for situations like
> this.

https://lists.fedorahosted.org/archives/list/packaging@lists.fedoraproject.org/thread/N5F425CNPDOWFPQODMMBOQ6Z4RQLCYCD/

@jgrulich if you're following this, my fork of the clazy packaging repo has a clang-12 branch which contains changes to update clazy to version 1.9, and to patch it so it builds against clang-12 (there was a post-release change upstream I had to pull in). On the plus side, the giant LLVM-11 patches that USED to be applied are no longer necessary.

I'd submit a PR to src.fedoraproject.org/rpms/clazy/, but I can't seem to log in right now — every attempt just gets me "Strange state: failure" so I guess the new accounts system is having some teething troubles.

Anyway, the branch diff against rawhide is here:

https://src.fedoraproject.org/fork/ferdnyc/rpms/clazy/diff/rawhide..clang-12

If you'd be up for taking a look at the branch, and hopefully applying it on both rawhide and f34, then submitting new builds of clazy against LLVM/clang 12, it'd be much appreciated. The versioned dependencies issue I asked about in my mailing list posting, I think can wait until the next round of changes, not worth holding up these fixes.

Let me know if you hit any issues or need anything else from me. If I can manage to get in to my account at src.fpo anytime soon I'll open a Real PR™ to go with the branch.

I did create a PR from your changes and merged them. Thank you for your help. I will submit updates once the builds finish.

FEDORA-2021-61b78213e0 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-61b78213e0

(In reply to Jan Grulich from comment #11)
> I did create a PR from your changes and merged them. Thank you for your
> help. I will submit updates once the builds finish.

Tested and working nicely in F34, thanks!

I would leave karma, but... I can't log in to bodhi, either, it seems.

500 Internal Server Error
Could not convert return value of the view callable function pyramid_fas_openid.view.verify_openid into a response object. The value returned was None. You may have forgotten to return a value from the view callable.

I guess I should start reporting these, since I assume not everyone is affected by this.

FEDORA-2021-61b78213e0 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-61b78213e0`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-61b78213e0

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Tested it, and it works on F34 now. Thanks for the efforts! So I think this one can be closed sooner or later...

FEDORA-2021-61b78213e0 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.