Created attachment 1862479 [details] Complete build.log Description of problem: When trying to compile datamash 1.7 on Fedora Rawhide for ppc64le, I'm getting this test failure: FAIL: tests/datamash-error-msgs =============================== datamash-error-msgs.pl: test e103: stderr mismatch, comparing e103.2 (expected) and e103.E (actual) *** e103.2 Mon Feb 21 19:56:53 2022 --- e103.E Mon Feb 21 19:56:53 2022 *************** *** 1 **** ! datamash: invalid trim mean value 12 (expected 0 <= X <= 0.5) --- 1 ---- ! datamash: invalid trim mean value 8.49793e-321 (expected 0 <= X <= 0.5) datamash-error-msgs.pl: test e104: stderr mismatch, comparing e104.2 (expected) and e104.E (actual) *** e104.2 Mon Feb 21 19:56:53 2022 --- e104.E Mon Feb 21 19:56:53 2022 *************** *** 1 **** ! datamash: invalid trim mean value 0.51 (expected 0 <= X <= 0.5) --- 1 ---- ! datamash: invalid trim mean value 8.50267e-321 (expected 0 <= X <= 0.5) FAIL tests/datamash-error-msgs.pl (exit status: 1) It does not happen when I compile it manually on RHEL-9. I will upload build.log and report the issue upstream to Assaf Gordon.
I have reproduced the issue on F36 as well: https://koji.fedoraproject.org/koji/taskinfo?taskID=83147443
F35 is not affected: https://koji.fedoraproject.org/koji/taskinfo?taskID=83148318
EPEL9 is not affected. In summary: datamash-error-msgs.pl fails for Fedora Rawhide and Fedora 36: Fedora Rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=83147370 F36: https://koji.fedoraproject.org/koji/taskinfo?taskID=83147408 Fedora 35 and RHEL-9 (EPEL9) are not affected. F35: https://koji.fedoraproject.org/koji/taskinfo?taskID=83148318 EPEL9: https://koji.fedoraproject.org/koji/taskinfo?taskID=83148666 I have also tried to transfer the datamash binary compiled for Fedora rawhide on ppc64le to ppc64le running RHEL-9.0.0-20220117.0 and datamash-error-msgs.pl fails there. It indicates that the problem might be due to the compilation.
Failing tests: https://github.com/agordon/datamash/blob/master/tests/datamash-error-msgs.pl#L210 Wrong output: ./datamash trimmean:12 1 ./datamash: invalid trim mean value 4.94066e-324 (expected 0 <= X <= 0.5) ./datamash trimmean:0.51 1 ./datamash: invalid trim mean value 4.92089e-323 (expected 0 <= X <= 0.5) Expected output: $datamash trimmean:12 1 datamash: invalid trim mean value 12 (expected 0 <= X <= 0.5) $datamash trimmean:0.51 1 datamash: invalid trim mean value 0.51 (expected 0 <= X <= 0.5)
I think the issue is caused by GCC bug - I have opened this BZ: Bug 2057524 - gcc (GCC) 12.0.1 - producing wrong code for error call with long double value on ppc64le
I got the update from Jakub Jelinek on BZ2057524: https://bugzilla.redhat.com/show_bug.cgi?id=2057524#c10 =============================================================================================== This is a bug on the datamash/gnulib side. For error declaration it uses #include "error.h" in src/system.h which picks up "lib/error.h": # 75 "src/system.h" 2 # 1 "lib/error.h" 1 # 52 "lib/error.h" extern void error (int __status, int __errnum, const char *__format, ...) __attribute__ ((__format__ (__printf__, 3, 4))); extern void error_at_line (int __status, int __errnum, const char *__fname, unsigned int __lineno, const char *__format, ...) __attribute__ ((__format__ (__printf__, 5, 6))); but that is some gnulib prototype for the function, not the glibc one, which is in <error.h> (i.e. /usr/include/error.h). That header provides similar declaration, but also includes <bits/error-ldbl.h> header in certain conditions which makes sure to redirect the error call to __ieee128_error for -mabi=ieeelongdouble on ppc64le (which is now the default in F36 and later). Now, it would be fine to use the ?gnulib? error.h if its implementation would be also used, but that doesn't seem to be the case and you are instead using the glibc definition. In any way, this has really nothing to do with gcc, it is a glibc vs. gnulib vs. the package issue. =============================================================================================== I will contact datamash maintainer to get this resolved.
I have found the root cause. Since Fedora36, the long double type on ppc64le has been moved to _Float128. The gnulib version of error.h which comes with datamash is not ready for this change. So it seems to me that gnulib has to be updated to the latest version to fix that. I have asked upstream to do that. Thanks a lot Jirka
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle. Changing version to 37.
How about putting something like sed '/# include "error.h"/d' src/system.h -i into the spec file until upstream fixes the issue? FWIW, it seems that the datamash maintainer changed recently, the last activity on the mailinglist is the discussion of the 1.8 announcement containing erroneous checksums for the release source archive files. Also, Jiri's upstream bug report didn't receive any reply. (cf. https://lists.gnu.org/archive/html/bug-datamash/2022-03/msg00000.html) AFAICS, the gnulib version is only required for non-glibc platforms, whereas Fedora is glibc based. I've tested this change with upstream datamash 1.8 under Fedora 37/x86_64 and there `make check` still succeeds. Alternatively, one could simply blacklist the ppc64le architecture. --- I think such a change is quite urgent because datamash was included in the `List of long term FTBFS packages` a few days ago. And thus there is a risk of datamash being retired at around 2023-02-08, if the build isn't going to be fixed.
I've tested an even simpler fix: iff --git a/datamash.spec b/datamash.spec index 1b2ed0f..124f943 100644 --- a/datamash.spec +++ b/datamash.spec @@ -36,6 +36,7 @@ files. %ifarch armv7hl %patch1 -p1 %endif +rm lib/error.* %build %configure This fixes the test suite on ppc64le: https://koji.fedoraproject.org/koji/taskinfo?taskID=96837291 (Also succeeds on x86_64, tested locally on Fedora 37.)
FEDORA-2023-ed734e6bba has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-ed734e6bba
FEDORA-2023-1fa3c954ca has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2023-1fa3c954ca
FEDORA-2023-1fa3c954ca has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-1fa3c954ca` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-1fa3c954ca See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-ed734e6bba has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-ed734e6bba` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-ed734e6bba See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-ed734e6bba has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-1fa3c954ca has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.