On 2025/01/19 18:32, Michael J Gruber wrote:
Mattia Verga venit, vidit, dixit 2025-01-19 18:28:04:For example: https://kojipkgs.fedoraproject.org//work/tasks/7044/127997044/build.log I don't know much of C, from what I've read online those functions are declared without arguments and then used with arguments. It seems this is now throwing an error, while before the mass rebuild just worked: /builddir/build/BUILD/libahp-gt-1.7.0-build/libahp-gt-1.7.0/ahp_gt.c: In function ‘synscan_poll’: /builddir/build/BUILD/libahp-gt-1.7.0-build/libahp-gt-1.7.0/ahp_gt.c:541:17: error: too many arguments to function ‘ahp_gt_get_tracking_mode’; expected 0, have 1 541 | ahp_gt_get_tracking_mode(cmd[0]); | ^~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~ In file included from /builddir/build/BUILD/libahp-gt-1.7.0-build/libahp-gt-1.7.0/ahp_gt.c:26: /builddir/build/BUILD/libahp-gt-1.7.0-build/libahp-gt-1.7.0/redhat-linux-build/ahp_gt.h:1037:16: note: declared here 1037 | DLL_EXPORT int ahp_gt_get_tracking_mode(); | ^~~~~~~~~~~~~~~~~~~~~~~~Yes, this is clearly fallout from gcc 15 landing in rawhide (just before the mass rebuild). It's not a gcc 15 bug, though. You could file upstream for gcc 15 / C23 standard compatibility.Either they had a typo or they wanted to abuse C interface (most likely the first one (off by 1 letter get->set)). This seems to be fixed upstream [1] anyway.
Maybe share the other example as well in case it is more clear that they really wanted to abuse C interface. This reads too much like a bug because in the supposedly "working" interface, they are passing an `int` that is being copied instead of a pointer and they are getting that as a return value.
[1]: https://github.com/ahp-electronics/libahp-gt/commit/324c0914e5dd3b23b5af5e871ba5dc0f790bddce
I have several other packages failing for the same reason:
libpasastro
https://koji.fedoraproject.org/koji/taskinfo?taskID=128001935
wcstools
https://koji.fedoraproject.org/koji/taskinfo?taskID=128160436
xephem
https://koji.fedoraproject.org/koji/taskinfo?taskID=12816284
I wonder if it's best practice for software to explicitly pass the standard in the build flags (with -std=...). I've checked a few which successfully passed the mass rebuild and those set a lower standard than C23 in flags.
BTW, other fail causes I see on my packages are:
libindi | phd2 | zxcvbn:
‘uint64_t’ is defined in header ‘<cstdint>’; this is
probably fixable by adding ‘#include <cstdint>’
Sounds easy to fix.
python-ducc0:
error: call of ‘(ducc0::detail_mav::vmav<double, 3>)
(int64_t&, int64_t, int64_t&)’ is ambiguous
I have no clue on this, need to get in contact with upstream.
indi-3rdparty-drivers:
error: expected ‘;’, identifier or ‘(’ before ‘bool’
Looks like the syntax 'typedef enum { FALSE, TRUE } bool;' is no
more accepted, but searching in the net it was perfectly fine.
Mattia
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
