groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ingo Schwarze
Subject: Re: [groff] 1.22.4.rc4 - Final RC before official 1.22.4
Date: Sun, 9 Dec 2018 13:59:11 +0100
User-agent: Mutt/1.8.0 (2017-02-23)

Hi Ralph,

Ralph Corderoy wrote on Sun, Dec 09, 2018 at 11:09:51AM +0000:
> Ingo Schwarze wrote:

>> To confirm this, i just commented out the line
>>
>>   double hypot(double, double);
>>
>> in /usr/include/math.h
> ...
>>     CXX      src/libs/libgroff/libgroff_a-hypot.o
>>   ../src/libs/libgroff/hypot.cpp:
>>     In function 'double groff_hypot(double, double)':
>>   ../src/libs/libgroff/hypot.cpp:25:
>>     error: 'hypot' was not declared in this scope
>>   *** Error 1 in . (Makefile:7241 'src/libs/libgroff/libgroff_a-hypot.o':
>>     @echo "  CXX     " src/libs/libgroff/libgroff_a-hypot.o;g++ -DHAVE_C...)
>>   *** Error 1 in /co/groff/build (Makefile:5453 'all')
>>
>> The lack of hypot() in libm is *not* detected

> Did you remove hypot() from libm.a too?

No i didn't.

For one thing, manipulating system libraries in a live system is much
harder (and more dangerous) than temporarily manipulating system headers.

Then, the test that the gnulib hypot module is supposed to replace
intends to test whether the function needs to be *declared*.  In
the past, our build system did not provide any replacement code for
a missing hypot() object in the system library.  It only attempted
to provide a missing declaration, if needed.

> If not, its presence might influence gnulib tests giving a mixed result
> because math.h is failing to prototype it.

I explained *twice* in different mails - including in the text you just
snipped - that my main point is that NO TEST WHSATSOEVER IS BEING RUN.
As i already explained, you can clearly see that by reading ./configure
and config.log.  So no test can be influenced.

And even if some test *were* run - if the lack of a declaration of
the function being tested for would make the build crash, quite
obviously, such a test would be horribly broken.  Lack of the
interface from the system headers is among the main problems such
a test is supposed to check, and crashing the build is among the
chief symptoms such a test is supposed to prevent...

The point of running on a deliberately broken system was merely TO
DEMONSTRATE ONE OBVIOUS WAY IN WHICH OUR CURRENT BUILD SYSTEM CODE
IS BROKEN.  Answering "but our current built system code might be
less broken in some other situation, or might it not?" makes very
little sense to me.


Hell, i *really* don't want to get into autoconf programming, but
i suspect that our configure.ac probably needs to call

  AC_CHECK_FUNCS([hypot])  or AC_REPLACE_FUNCS([hypot])

or something like that.  Not sure what exactly, but *some* magical
incantation is clearly missing somewhere.


By the way, looking at configure.ac, my impression is that redundant,
maybe even conflicting tests are likely being done for several
functions, for example GROFF_NEED_DECLARATION + AC_REPLACE_FUNCS
for strcasecmp(3) and GROFF_NEED_DECLARATION + AC_CHECK_FUNCS for
gettimeofday(2).  But if so, that should be cleaned up *after*
release.  Besides, my impression may be mistaken, as i said, autoconf
is quite contorted and certainly hard to understand.

Yours,
  Ingo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]