Closed kloczek closed 1 year ago
On test suite execution it fails with:
Am Mittwoch, 26. April 2023, 04:10:34 CEST schrieb Tomasz Kłoczko:
Hi Tomasz,
I'm not 100% sure is it test suite issue or it is something wrong with latest clang 16.0.2. I'm not sure what I shpould provide as details whcih could help diagnose this issue so please let me know if you need something.
The log looks like a crasher of the clang compiler. At least it compiles with my (older) clang. Do you happen to have a (slightly) older clang to test?
Thanks.
Ciao Stephan
The log looks like a crasher of the clang compiler. At least it compiles with my (older) clang. Do you happen to have a (slightly) older clang to test?
I just found that I've reported simillar issue with older clang https://github.com/smuellerDD/libkcapi/issues/108
OK will try to open one more time LLV ticket. Maybe thi stime it will be investigated.
Am Mittwoch, 26. April 2023, 11:08:10 CEST schrieb Tomasz Kłoczko:
Hi Tomasz,
The log looks like a crasher of the clang compiler. At least it compiles with my (older) clang. Do you happen to have a (slightly) older clang to test? I just found that I've reported simillar issue with older clang https://github.com/smuellerDD/libkcapi/issues/108
OK will try to open one more time LLV ticket. Maybe thi stime it will be investigated.
My compiler from Fedora as follows works:
$ clang --version clang version 16.0.1 (Fedora 16.0.1-1.fc38) Target: x86_64-redhat-linux-gnu Thread model: posix InstalledDir: /usr/bin
Ciao Stephan
I'm using my own binaries with 16.0.2. libkcapi is only project in which clang crashes.
Am Mittwoch, 26. April 2023, 12:16:58 CEST schrieb Tomasz Kłoczko:
Hi Tomasz,
I'm using my own binaries with 16.0.2. libkcapi is only project in which clang crashes.
Note, it is not clang, it is clang-scan that seemingly crashes. What about you do not use the build target "scan"?
Ciao Stephan
Just checked what I have in libkcapi.spec and ..
%check
%{!?with_check:exit 0}
#%make_build cppcheck
%make_build scan
OK so you are right.
May I ask you try scan
target in your build env? 😋
BTW just checked and looks like there is no standard check
target.
+ /usr/bin/make -O -j48 V=1 VERBOSE=1 check
Makefile:2026: warning: overriding recipe for target 'lib/doc/bin/docproc'
Makefile:993: warning: ignoring old recipe for target 'lib/doc/bin/docproc'
make: Nothing to be done for 'check'.
Hmm .. 🤔
Am Mittwoch, 26. April 2023, 13:42:12 CEST schrieb Tomasz Kłoczko:
Hi Tomasz,
BTW just checked and looks like there is no standard
check
target.+ /usr/bin/make -O -j48 V=1 VERBOSE=1 check Makefile:2026: warning: overriding recipe for target 'lib/doc/bin/docproc' Makefile:993: warning: ignoring old recipe for target 'lib/doc/bin/docproc' make: Nothing to be done for 'check'.
Hmm .. 🤔
The check target to me seems more like a self-test that all is proper rather than invoking the static code analyzer, no?
Ciao Stephan
The check target to me seems more like a self-test that all is proper rather than invoking the static code analyzer, no? Ciao
Usually test suite tests just generated binaries (excutables or DSO rourines) to make sure that at lease some basic functionalities are working as expected ..
Am Mittwoch, 26. April 2023, 14:14:17 CEST schrieb Tomasz Kłoczko:
Hi Tomasz,
The check target to me seems more like a self-test that all is proper rather than invoking the static code analyzer, no? Ciao Usually test suite tests just generated binaries (excutables or DSO rourines) to make sure that at lease some basic functionalities are working as expected ..
That would always require the build system to have the kernel AF_ALG interface to be present. IMHO this is not what you can assume to be present in all cases. Then we have cross compiles. To me this all rules out such "sanity" test.
Ciao Stephan
That would always require the build system to have the kernel AF_ALG interface to be present. IMHO this is not what you can assume to be present in all cases. Then we have cross compiles. To me this all rules out such "sanity" test. Ciao Stephan
It is possible to check that in autoconf and than show message that such test suire will be not executed in check
target because it is something missing in kernel running build env.
Am Mittwoch, 26. April 2023, 14:20:48 CEST schrieb Tomasz Kłoczko:
Hi Tomasz,
That would always require the build system to have the kernel AF_ALG interface to be present. IMHO this is not what you can assume to be present in all cases. Then we have cross compiles. To me this all rules out such "sanity" test. Ciao Stephan It is possible to check that in autoconf and than show message that such test suire will be not executed in
check
target because it is something missing in kernel running build env.
If you think you have a good apporach, patches are welcome :-)
Ciao Stephan
Maybe later as I'm a bit busy with other things 😋 FYI: https://github.com/llvm/llvm-project/issues/62385
Can you confirm tht with fedora binaries scan
targer is not crashing? 🤔
Am Mittwoch, 26. April 2023, 14:39:48 CEST schrieb Tomasz Kłoczko:
Hi Tomasz,
Can you confirm tht with fedora binaries
scan
targer is not crashing? 🤔
Confirmed. I also made sure the C file that caused the crash was part of my clang-scan run.
Ciao Stephan
Someone made maybe some progress on that issue? 🤔
Am Freitag, 1. September 2023, 19:07:19 CEST schrieb Tomasz Kłoczko:
Hi Tomasz,
Someone made maybe some progress on that issue? 🤔
What progress do you expect on my side? The clang-scan tool is crashing.
Ciao Stephan
This is seemingly no bug in libkcapi, closing
I'm not 100% sure is it test suite issue or it is something wrong with latest clang 16.0.2. I'm not sure what I shpould provide as details whcih could help diagnose this issue so please let me know if you need something.