Il 19/01/25 19:02, Cristian Le via devel ha scritto:
> 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
