Hi all,
I'm looking through F33 FTBFS issues, and I see an increasing number of packages that fail to build because their test suites (using check) fail to build with errors like this:
/usr/include/check.h:502:27: note: declared here 502 | CK_DLL_EXP void CK_EXPORT _ck_assert_failed(const char *file, int line, | ^~~~~~~~~~~~~~~~~ path_utils/path_utils_ut.c:698:3: error: too few arguments to function '_ck_assert_failed'
For example, gsignond-plugin-oauth, gsignond-plugin-sasl, libaccounts-glib, signon-glib, ding-libs fail with these issues.
Any idea if that's a problem with the "check" 0.15.x builds themselves, or if packages need to adapt to changed API here?
Fabio
On Sun, Aug 2, 2020 at 9:55 AM Fabio Valentini decathorpe@gmail.com wrote:
I'm looking through F33 FTBFS issues, and I see an increasing number of packages that fail to build because their test suites (using check) fail to build with errors like this:
/usr/include/check.h:502:27: note: declared here 502 | CK_DLL_EXP void CK_EXPORT _ck_assert_failed(const char *file, int line, | ^~~~~~~~~~~~~~~~~ path_utils/path_utils_ut.c:698:3: error: too few arguments to function '_ck_assert_failed'
For example, gsignond-plugin-oauth, gsignond-plugin-sasl, libaccounts-glib, signon-glib, ding-libs fail with these issues.
Any idea if that's a problem with the "check" 0.15.x builds themselves, or if packages need to adapt to changed API here?
You can point the finger of blame at least partly at me for this. Version 0.15.0 of check introduced the use of __attribute__((printf....)) to check the arguments to some of the calls. However, upstream didn't do it right, with the result that gcc warned on pretty much every use of the check macros. I submitted a patch upstream to fix that, which upstream applied and included in version 0.15.1. That patch, however, broke other things, such as the ability to call fail_if() with only one argument.
I've been working on another patch to fix *that*. It's not too hard to do for gcc, which makes __VA_OPT__ available to the C compiler, but not so easy for the Microsoft compiler. I'll attach what I have so far. Comments or suggestions on how to make it better are much appreciated. I would like to submit something upstream by tomorrow. If upstream likes the idea, I'll do another build of check that includes the patch.
On Sun, Aug 2, 2020 at 11:27 AM Jerry James loganjerry@gmail.com wrote:
You can point the finger of blame at least partly at me for this. Version 0.15.0 of check introduced the use of __attribute__((printf....)) to check the arguments to some of the calls. However, upstream didn't do it right, with the result that gcc warned on pretty much every use of the check macros. I submitted a patch upstream to fix that, which upstream applied and included in version 0.15.1. That patch, however, broke other things, such as the ability to call fail_if() with only one argument.
I've been working on another patch to fix *that*. It's not too hard to do for gcc, which makes __VA_OPT__ available to the C compiler, but not so easy for the Microsoft compiler. I'll attach what I have so far. Comments or suggestions on how to make it better are much appreciated. I would like to submit something upstream by tomorrow. If upstream likes the idea, I'll do another build of check that includes the patch.
Upstream went with a simpler fix. It seems that the fail_* macros are deprecated anyway (your upstreams should switch to using ck_assert* calls instead), so they just added an extra NULL argument to the end. That will make GCC complain about too many arguments for the format string in the case that more than one argument is passed, but will fix the breakage when only one argument is passed.
I will add upstream's commit to the our package and rebuild.
On Mon, Aug 3, 2020 at 8:32 PM Jerry James loganjerry@gmail.com wrote:
On Sun, Aug 2, 2020 at 11:27 AM Jerry James loganjerry@gmail.com wrote:
You can point the finger of blame at least partly at me for this. Version 0.15.0 of check introduced the use of __attribute__((printf....)) to check the arguments to some of the calls. However, upstream didn't do it right, with the result that gcc warned on pretty much every use of the check macros. I submitted a patch upstream to fix that, which upstream applied and included in version 0.15.1. That patch, however, broke other things, such as the ability to call fail_if() with only one argument.
I've been working on another patch to fix *that*. It's not too hard to do for gcc, which makes __VA_OPT__ available to the C compiler, but not so easy for the Microsoft compiler. I'll attach what I have so far. Comments or suggestions on how to make it better are much appreciated. I would like to submit something upstream by tomorrow. If upstream likes the idea, I'll do another build of check that includes the patch.
Upstream went with a simpler fix. It seems that the fail_* macros are deprecated anyway (your upstreams should switch to using ck_assert* calls instead), so they just added an extra NULL argument to the end. That will make GCC complain about too many arguments for the format string in the case that more than one argument is passed, but will fix the breakage when only one argument is passed.
I will add upstream's commit to the our package and rebuild.
Thanks! It looks like the packages which are using those macros in their test suites now build correctly. They'll get resubmitted by my "resubmit this if the F33FTBFS issue was caused by a transient issue" script soon. :)
Fabio
-
Fabio Valentini -
Jerry James