Re: [groff] 1.22.4.rc4 - Final RC before official 1.22.4

[Bertrand Garrigues]

Hi Ingo,

On Sat, Dec 08 2018 at 08:06:11 PM, Ingo Schwarze <address@hidden> wrote:
> incidentally, i did an update of my OpenBSD-current base system
> since building the last groff release tarball three days ago.
> The system now uses the LLVM linker by default instead of the GNU
> binutils linker:
[...]
> I do not see any regressions so far.  So now we also know that it is
> possible to build this groff release with the complete LLVM toolchain.

That's a good thing,

> Bertrand Garrigues wrote on Sat, Dec 08, 2018 at 01:07:26AM +0100:
>> Yes the test is buggy.  On my GNU/Linux system the test always says
>> 'yes' although I obviously don't need the declaration.  I think we can
>> get ride of that one and replace it by gnulib's hypot module.  The patch
>> below fixes the build on Solaris 11 (need to call 'bootstrap' and
>> regenerate the tarball with 'make dist').  I'll do more tests this
>> weekend.
>
> Applying your patch, building a new release tarball, and testing that
> on OpenBSD-current, Debian Jessie, and Solaris 11, everything works.

I've also made some more tests.  As I haven't found any issue I've
commited my patch.

> On Solaris 10, Perl 5.8.4 is in use.  On that ancient version of Perl,
> Deri's latest gropdf(1) endianness fix is ineffective because support
> for "L<" appears to be broken in unpack(3p).
[...]
> I don't think we should attempt to work around that ancient Perl bug.
> I mean, srsly, Perl 5.8.4 in 2018?

I can't judge if it would be easy or not to work around this problem (I
let Deri comment on that), but I agree that it's probably not worth
spending too much time on it.

> But the following seems suspicious (on OpenBSD):
>
>    $ grep hypot ../configure
>   gl_hypot_required=plain
>     # Code from module hypot:
>     gl_LIBOBJS="$gl_LIBOBJS hypot.$ac_objext"
>
>    $ grep hypot config.log config.status
>   [ no output ]
>
>    $ find . -name '*hypot*'
>   ./src/libs/libgroff/.deps/libgroff_a-hypot.Po
>   ./src/libs/libgroff/libgroff_a-hypot.o
>   ./lib/.deps/hypot.Po
>
> Nothing whatsoever is tested, and looking at src/libs/libgroff/hypot.cpp,
> it is merely a completely trivial wrapper.
>
> So what is the gnulib "hypot" module supposed to do?
> If it does nothing, why do you even use it?

For most of its modules, gnulib provides a m4 macro to check if a given
function is broken on the current system (here 'gnulib_m4/hypot.m4') and
a replacement function (here 'gnulib/lib/hypot.c').  If gnulib sees that
the hypot on your system is broken it will make you use its own function
instead (the only thing is that you must include <config.h> first in the
file that uses the function).  Otherwise (like on your system, or mine)
nothing happens and you use directly the 'hypot' function of your
system.  In 'configure' the replacement of the system's 'hypot' by
gnulib's 'hypot' is done here:

   if test $REPLACE_HYPOT = 1; then

As the 'GROFF_NEED_DECLARATION([hypot])' call was doing some (home-made)
compatibility checks, probably that means some compatibility issues were
found before on 'hypot'.  That's why I thought I would be safer to add
gnulib's 'hypot' module.

Regards,

Bertrand