Re: gnulib inclusion error exposed by Linux ppc64le build

[Erik Auerswald]

Hi,

On 08.04.23 19:53, Erik Auerswald wrote:
> On 02.04.23 18:40, Georg Sauthoff wrote:
> > Hello,
> >
> > I'm the new Fedora datamash package maintainer.
> >
> > This was reported previously on this list (cf.
> > https://lists.gnu.org/archive/html/bug-datamash/2022-03/msg00000.html),
> > but it's still an issue with tht latest Datamash 1.8 release.
> >
> > See also https://bugzilla.redhat.com/show_bug.cgi?id=2056736 for
> > the old Fedora bug report.
>
> In comment #6[0] of that bug report, some problem with the
> Gnulib "error" module is diagnosed.  It seems as if this
> module lacks special handling for PPC64LE with 128bit long
> double.  Then there is a confusing statement regarding use
> of only the Gnulib _definition_, but not _implementation_
> of the error() function.
>
> [0] <https://bugzilla.redhat.com/show_bug.cgi?id=2056736#c6>

It is possible that this problem is accidentally fixed in Gnulib,
because on 2023-01-12, the "error" module was split into two, i.e.,
"error-h" to provide "lib/error.h" and "error" to provide
"lib/error.c" with a dependency on the new "error-h".  This also
removed "lib/error.h" and replaced it with "lib/error.in.h" from
which to generate "lib/error.h" if required.  There have been
additional commits to the "error" resp. "error-h" modules in
January 2023.

It seems plausible that current Gnulib would not provide the
"lib/error.h" header if a system-provided version were found.

Thus I'd say that attempting to update to current Gnulib might
fix this PPC64LE problem.

I still have no idea how to work with Gnulib, and I still cannot
test the result on PPC64LE, but this might be a way forward.

References:

* "error: Work around an Android problem."

<https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=2886cca8398f4c5a4d68368a19c0e6d0ff97c739>

* "Resolve conflicts for functions introduced in Android API level 23."

<https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=eaf067b33e6883af540f72340400eabd9f79c029>

Best regards,
Erik