Re: overfull box in printed toc with @/

[Gavin Smith]

On Tue, Sep 19, 2023 at 10:51:26AM -0600, Karl Berry wrote:
> Hi Gavin - with this input file:
> 
> \input texinfo
> @contents
> @chapter Test
> @section Sec
> @subsection 
> foofoo@code{\DeclareRobustCommand@{@var{cmd}@}[@var{num}][@var{default}]@/@{@var{definition}@}
>  }
> @bye
> 
> I get an overfull box in the toc (texinfo.tex version 2023-09-12.17):
> 
> Overfull \hbox (65.62492pt too wide) in paragraph at lines 3--3
>  [][][]@textrm foofoo@texttt \DeclareRobustCommand{@textttsl cmd@texttt 
> }[@text
> ttsl num@texttt ][@textttsl default@texttt ] |
> 
> The subsection title is painfully long, but it has to be, so I inserted
> an @/ to allow a line break. The break happens but the line before the
> break gets an overfull box, although no text is near the margin.
> I'll attach the pdf I got (and .log, what the heck). --thanks, karl.
> 

I had a change to this code sitting waiting to make, and when I tried
it, it fixed this problem.  It removed some code (which I'd added
myself in the past), and in this case simpler is evidently better.

So I've commited the change, rather than waiting until after the next
release, as I'd previously intended.

Please let us know if the change works ok with your manual and if there
are any regressions.

Re: Texinfo 7.0.92 pretest on NetBSD 9.0

[Patrice Dumas]

On Tue, Sep 19, 2023 at 08:33:08PM +0100, Gavin Smith wrote:
> 
> This shows how using new gnulib modules can lead to problems, especially
> under the tp/Texinfo/XS directory.

We need to use libunistring quite a bit to be on par with the perl code
on everything related to unicode.

> I don't know what problem the libunistring module was supposed
> to fix.  Commit 3ded9f090 (2023-09-01) adds the module but it's not
> clear how or why it's used - I couldn't see anything in nearby commits.

It is needed, it was an oversight of me not to add it previously, it has
been needed since I added uniconv/u8-strconv-from-enc unistr/u8-mbsnlen
in 
https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=0bfbc74287b9b85c63f9fc850d17b035e8aa32fb

I added a retrospective Changelog more recently in
https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=0e484c586858de92a8ec7850d96472d3c22d6afa

> Could we not just revert adding the module and that would fix the
> problem?

No, and it would even fail if the system libunistring is used, it is
that failure that made me realize that this module was needed.

-- 
Pat

Re: Texinfo 7.0.92 pretest on NetBSD 9.0

[Gavin Smith]

On Tue, Sep 19, 2023 at 07:43:26PM +0200, Patrice Dumas wrote:
> Hello,
> 
> Thanks for the analysis!
> 
> On Tue, Sep 19, 2023 at 04:22:42PM +0200, Bruno Haible wrote:
> > * But you can see from the log above that no -I option is in use that
> >   allows the compiler to find the *installed* .
> > * The 'libunistring' module puts the necessary -I options into the CPPFLAGS
> >   variable, as documented in
> >   
> > https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/libunistring.m4;h=15702811764c2812ad5fe91c2407aff0a55603b9;hb=HEAD
> > * But in build/tp/Texinfo/XS/config.status the value of the CPPFLAGS
> >   variable is empty.
> > 
> > The origin of the bug is here:
> > $ grep -n CPPFLAGS= tp/Texinfo/XS/configure.ac /dev/null 
> > tp/Texinfo/XS/configure.ac:100:  CPPFLAGS=$PERL_EXT_CPPFLAGS
> 
> I think that the first one is not such an issue, as it is set quite
> early, the libunistring module is called afterwards.  Yet it would be
> better to save and reset CPPFLAGS anyway to be cleaner here.
> 
> > tp/Texinfo/XS/configure.ac:152:CPPFLAGS=$PERL_EXT_CPPFLAGS
> 
> This one will do as you say, throw away the -I options.  Maybe it could
> be enough to remove the three lines outside of
>   if test x$disable_xs != xyes; then
> defining those when $disable_xs = no seems actually confusing.
> 
> CFLAGS=$PERL_EXT_CFLAGS
> CPPFLAGS=$PERL_EXT_CPPFLAGS
> LDFLAGS=$PERL_EXT_LDFLAGS
> 
> and, in addition, in the test in if test x$disable_xs != xyes; block
> save and reset the variables.

This shows how using new gnulib modules can lead to problems, especially
under the tp/Texinfo/XS directory.

I don't know what problem the libunistring module was supposed
to fix.  Commit 3ded9f090 (2023-09-01) adds the module but it's not
clear how or why it's used - I couldn't see anything in nearby commits.

Could we not just revert adding the module and that would fix the
problem?

Re: Texinfo 7.0.92 pretest on NetBSD 9.0

[Patrice Dumas]

On Tue, Sep 19, 2023 at 04:22:42PM +0200, Bruno Haible wrote:
> The origin of the bug is here:
> $ grep -n CPPFLAGS= tp/Texinfo/XS/configure.ac /dev/null 
> tp/Texinfo/XS/configure.ac:100:  CPPFLAGS=$PERL_EXT_CPPFLAGS
> tp/Texinfo/XS/configure.ac:152:CPPFLAGS=$PERL_EXT_CPPFLAGS

Here is a proposal for a patch.  It still sets

  CFLAGS=$PERL_EXT_CFLAGS
  CPPFLAGS=$PERL_EXT_CPPFLAGS
  LDFLAGS=$PERL_EXT_LDFLAGS

early on, such that CPPFLAGS and other flags are added to that.
I removed the other perl flags because that were previously set
at the point in the configure.ac file because I did not understand why
they would be relevant here for the gnulib macros invokations, but I may
have missed something.

I removed the setting of CFLAGS, CPPFLAGS and LDFLAGS late in
configure.ac.

I made another unrelated change, I added $(PERL_CONF_cccdlflags) to
AM_CFLAGS in Makefile.am, as it seems to me that it would be missing
there, if I understood the documentation correctly.  My feeling is that
it worked previously without that kind of flags because it is also added
by libtool, but it seems to me to be cleaner to have it there.

I can make it a proper commit with Changelog if the approach seems ok.

-- 
Pat
diff --git a/tp/Texinfo/XS/Makefile.am b/tp/Texinfo/XS/Makefile.am
index fadc42d816..9c54beee0a 100644
--- a/tp/Texinfo/XS/Makefile.am
+++ b/tp/Texinfo/XS/Makefile.am
@@ -65,7 +65,7 @@ install-data-hook:
 EXTRA_DIST += TestXS.xs XSParagraph.xs MiscXS.xs
 
 
-AM_CFLAGS = $(PERL_CONF_ccflags) $(PERL_CONF_optimize)
+AM_CFLAGS = $(PERL_CONF_ccflags) $(PERL_CONF_optimize) $(PERL_CONF_cccdlflags)
 AM_CFLAGS += -DVERSION=\"$(VERSION)\" -DXS_VERSION=\"$(VERSION)\"
 AM_CFLAGS += -I$(PERL_INC)
 
diff --git a/tp/Texinfo/XS/configure.ac b/tp/Texinfo/XS/configure.ac
index b9f9fcf658..ccecd43fcc 100644
--- a/tp/Texinfo/XS/configure.ac
+++ b/tp/Texinfo/XS/configure.ac
@@ -96,9 +96,9 @@ if test x$disable_xs != xyes; then
   # Override these variables set by configure at the top level, because 
   # the compiler used in this subdirectory might be different.
   # Change these now so they are used in the checks that follow.
-  CFLAGS="$PERL_EXT_CFLAGS $PERL_CONF_ccflags"
+  CFLAGS=$PERL_EXT_CFLAGS
   CPPFLAGS=$PERL_EXT_CPPFLAGS
-  LDFLAGS="$PERL_EXT_LDFLAGS $PERL_CONF_ccdlflags $PERL_CONF_cccdlflags"
+  LDFLAGS=$PERL_EXT_LDFLAGS
   
   lookup_perl_conf([libperl])
   # Change libperl.so into -lperl to indicate a library dependency to 
@@ -147,10 +147,9 @@ AM_CONDITIONAL([HAVE_ICONV],
[test "x$am_func_iconv" = "xyes"])
 
 
-# Do not include Perl configuration values when outputting these variables
-CFLAGS=$PERL_EXT_CFLAGS
-CPPFLAGS=$PERL_EXT_CPPFLAGS
-LDFLAGS=$PERL_EXT_LDFLAGS
+# for per code, should use something along
+#CFLAGS="$CFLAGS $PERL_CONF_ccflags $PERL_CONF_cccdlflags"
+#LDFLAGS="$LDFLAGS $PERL_CONF_ccdlflags"
 
 AC_CONFIG_FILES([Makefile gnulib/lib/Makefile])
 AC_OUTPUT

Re: Texinfo 7.0.92 pretest on NetBSD 9.0

[Bruno Haible]

Hi Patrice,

> As a side note, it would have been better to have a specific variable
> like LTLIBUNISTRING instead of using the global CPPFLAGS, but it is not
> a big deal either.

The absence of such a variable INCLIBUNISTRING is a trade-off between
convenience and complexity.

-L and -Wl options are collected in $LIBUNISTRING or $LTLIBUNISTRING
because typically only selected binaries of a package need to be linked
with libunistring; the other binaries should not see an increased startup
time or memory footprint.

The situation is different for -I options:
  - It's harmless to have additional (possibly unused) -I options in $CPPFLAGS.
  - It simplifies the Makefile to have all -I options in $CPPFLAGS.
  - It also simplifies further configure tests if there's no need to
explicitly add $INCLIBUNISTRING to CPPFLAGS.

I first did it like this with libintl, ca. 25 years ago, and this approach
to modify CPPFLAGS works fine, except there were problems with config.cache
and early (old) versions of autoconf IIRC.

Bruno

Re: Texinfo 7.0.92 pretest on CentOS Stream 9

[Gavin Smith]

On Tue, Sep 19, 2023 at 06:02:09PM +0200, Patrice Dumas wrote:
> Hello Bruno,
> 
> The issue seems to be Unicode::Normalize missing.  This is not
> surprising if Centos is aiming for a minimalist default perl
> interpreter.
> 
> A simple fix would be to require it in the
>   [Perl version and modules]
> configure.ac check.  Gavin, would that be ok?

Yes that it is the easiest and quickest fix.

Re: Texinfo 7.0.92 pretest on AIX 7.3.1

[Gavin Smith]

On Tue, Sep 19, 2023 at 03:29:57PM +0200, Bruno Haible wrote:
> This is already fixed by gnulib commit
> https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=17c85713388407841f5c9978ecb3ccaf34ef76f1
> Interestingly, texinfo/tp/Texinfo/XS/gnulib/lib/stddef.in.h has the fix
> but texinfo/gnulib/lib/stddef.in.h does not.

Thanks, I'll update the gnulib import.

> I would have expected that you have a policy regarding which gnulib
> version to use (maybe the newest one, one week before release?
> or one of the stable branches [1]?), and am surprised to see that
> two parts of the texinfo git use different policies.

Basically, I had not thought it worth updating gnulib between pretests.
Once a pretest is out and tested, and builds successfully on some platforms,
I am loth to update gnulib again and risk breaking the build.

In the past we have done gnulib updates once before a series of pretests, and
then only update them if bugs are found in gnulib code in Texinfo (known about
based on reports of Texinfo pretests).

At the time of a release, the Gnulib checkout is set in stone.  It will not
be updated as a matter of course for any bug-fix releases; it would only
be deliberately updated if there was an apparent bug or reported compatability
issue.  This is to reassure users and distributors that we are making
minimal changes in bug-fix releases.  Many Gnulib changes may be
inconsequential or not relevant for Texinfo.  In view of this, there seems
to be little downside to fixing the Gnulib checkout at the time of the
first pretest, rather than at the eventual release.

As Patrice said in his mail, one of the gnulib imports was updated when
he imported a new module.  There may have been good reasons at the time (we
didn't discuss it) but in general I would like to be cautious about adding
new gnulib modules, especially between pretests.  It's best to discuss this
before changing anything.

I did not know about the stable branches of gnulib, and using one of these
is a possibility, but this might reduce testing of gnulib itself.  In the
past, Texinfo prereleases have occasionally found bugs in gnulib, and it
seems that using a recent development version of gnulib is a way to improve
the quality of gnulib.

Another way, I guess, is for me to check the recent gnulib ChangeLog for
any relevant changes, but this would be very hard for me to do, I expect, as
I wouldn't know which changes were important to include.

I am not saying that this is the right way of doing things, but this is
what my thought process was.  I'm open to other suggestions of ways of
doing it, ways that make it easier or better to develop either Texinfo,
or indeed Gnulib.

In short, I do not mind always updating gnulib to the latest version,
provided that platform testers repeat all their tests when we issue a
new prerelease distribution, to avoid regressions.  However, there's
no guarantee that this will happen.

Re: Texinfo 7.0.92 pretest on CentOS 8-stream

[Bruno Haible]

Patrice Dumas wrote:
> > So, as I understand it, this test failure will remain.
> 
> Actually it should not, the test should have been skipped, it was
> supposed to be fixed by this commit:
> 
> https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=e34a8d6b66d0518a2c1673da62c56b60f87151e3

This commit fixes it; thanks. But I was testing the 7.0.92 from a few days ago.

Bruno

Re: Texinfo 7.0.90 pretest on CentOS 8-stream (Unicode::Collate)

[Bruno Haible]

Patrice Dumas wrote:
> > FAIL: different_encodings.sh
> 
> There was the same kind of errors on N Beebe builds (I missed your
> original report).  It is is supposed to be fixed by
> https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=e34a8d6b66d0518a2c1673da62c56b60f87151e3

I confirm: With this patch, the test failure becomes a SKIP.

Bruno

Re: "error: too deeply nested expressions" for large Perl input file

[Gavin Smith]

On Mon, Sep 18, 2023 at 09:05:45PM +0200, Bruno Haible wrote:
> Gavin Smith wrote:
> > In gettext 0.22, there is an error running xgettext with a large input
> > file:
> > 
> > $ /usr/local/bin/xgettextHTML.pm 
> > HTML.pm:8052: error: too deeply nested expressions
> > 
> > This makes "make update-po" break in the Texinfo package.
> 
> Thanks for the report. Fixed through .

I appreciate your work on this issue and on gettext.

Re: Texinfo 7.0.92 pretest on NetBSD 9.0

[Patrice Dumas]

Hello,

Thanks for the analysis!

On Tue, Sep 19, 2023 at 04:22:42PM +0200, Bruno Haible wrote:
> * But you can see from the log above that no -I option is in use that
>   allows the compiler to find the *installed* .
> * The 'libunistring' module puts the necessary -I options into the CPPFLAGS
>   variable, as documented in
>   
> https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/libunistring.m4;h=15702811764c2812ad5fe91c2407aff0a55603b9;hb=HEAD
> * But in build/tp/Texinfo/XS/config.status the value of the CPPFLAGS
>   variable is empty.
> 
> The origin of the bug is here:
> $ grep -n CPPFLAGS= tp/Texinfo/XS/configure.ac /dev/null 
> tp/Texinfo/XS/configure.ac:100:  CPPFLAGS=$PERL_EXT_CPPFLAGS

I think that the first one is not such an issue, as it is set quite
early, the libunistring module is called afterwards.  Yet it would be
better to save and reset CPPFLAGS anyway to be cleaner here.

> tp/Texinfo/XS/configure.ac:152:CPPFLAGS=$PERL_EXT_CPPFLAGS

This one will do as you say, throw away the -I options.  Maybe it could
be enough to remove the three lines outside of
  if test x$disable_xs != xyes; then
defining those when $disable_xs = no seems actually confusing.

CFLAGS=$PERL_EXT_CFLAGS
CPPFLAGS=$PERL_EXT_CPPFLAGS
LDFLAGS=$PERL_EXT_LDFLAGS

and, in addition, in the test in if test x$disable_xs != xyes; block
save and reset the variables.

I will try to come up with something.

As a side note, it would have been better to have a specific variable
like LTLIBUNISTRING instead of using the global CPPFLAGS, but it is not
a big deal either.

-- 
Pat

overfull box in printed toc with @/

[Karl Berry]

Hi Gavin - with this input file:

\input texinfo
@contents
@chapter Test
@section Sec
@subsection 
foofoo@code{\DeclareRobustCommand@{@var{cmd}@}[@var{num}][@var{default}]@/@{@var{definition}@}
 }
@bye

I get an overfull box in the toc (texinfo.tex version 2023-09-12.17):

Overfull \hbox (65.62492pt too wide) in paragraph at lines 3--3
 [][][]@textrm foofoo@texttt \DeclareRobustCommand{@textttsl cmd@texttt }[@text
ttsl num@texttt ][@textttsl default@texttt ] |

The subsection title is painfully long, but it has to be, so I inserted
an @/ to allow a line break. The break happens but the line before the
break gets an overfull box, although no text is near the margin.
I'll attach the pdf I got (and .log, what the heck). --thanks, karl.



txilongsec.pdf
Description: Adobe PDF document


txilongsec.log
Description: Binary data

Re: Texinfo 7.0.92 pretest on AIX 7.3.1

[Patrice Dumas]

On Tue, Sep 19, 2023 at 03:29:57PM +0200, Bruno Haible wrote:
> 
> I would have expected that you have a policy regarding which gnulib
> version to use (maybe the newest one, one week before release?
> or one of the stable branches [1]?), and am surprised to see that
> two parts of the texinfo git use different policies.

We do not really have a policy.  My guess is that when I added some
libunistring code we used without properly taking from gnulib, I used a
more recent gnulib version in tp/Texinfo/XS, while the main directory
gnulib code was not updated.

Gavin, will you fix that, or should I do it?

-- 
Pat

Re: Texinfo 7.0.92 pretest on CentOS Stream 9

[Patrice Dumas]

Hello Bruno,

The issue seems to be Unicode::Normalize missing.  This is not
surprising if Centos is aiming for a minimalist default perl
interpreter.

A simple fix would be to require it in the
  [Perl version and modules]
configure.ac check.  Gavin, would that be ok?


Thanks for the report anyway!

On Tue, Sep 19, 2023 at 03:41:43PM +0200, Bruno Haible wrote:
> On CentOS Stream 9, "make check" fails with 52 test failures.
> 
> Find attached the log files.
> 

Re: Texinfo 7.0.90 pretest on CentOS 8-stream (Unicode::Collate)

[Patrice Dumas]

On Sat, Aug 19, 2023 at 03:25:48PM +0200, Bruno Haible wrote:
> Gavin Smith wrote:
> > I've added such a stub and added a test to configure, so that a visible
> > warning will be printed at the end of a configure run warning about missing
> > Unicode::Collate.
> 
> On CentOS 8 and CentOS 8-stream, the build now succeeds, but there is 1 test
> failure:
> 
> FAIL: different_encodings.sh
> 

There was the same kind of errors on N Beebe builds (I missed your
original report).  It is is supposed to be fixed by
https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=e34a8d6b66d0518a2c1673da62c56b60f87151e3

-- 
Pat

Re: Texinfo 7.0.92 pretest on CentOS 8-stream

[Patrice Dumas]

On Tue, Sep 19, 2023 at 03:37:02PM +0200, Bruno Haible wrote:
> On CentOS 8-stream, I still see this test failure:
> 
> FAIL: different_encodings.sh
> 
> Already reported in
> https://lists.gnu.org/archive/html/bug-texinfo/2023-08/msg00053.html
> 
> Last time, you wrote:
> > Even though there is
> > a stub for Unicode::Collate, the tests will not all pass without it.
> > "configure" prints a warning about index sorting so users should not be
> > too surprised if the tests fail.
> 
> So, as I understand it, this test failure will remain.

Actually it should not, the test should have been skipped, it was
supposed to be fixed by this commit:

https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=e34a8d6b66d0518a2c1673da62c56b60f87151e3

I will also say it in the original thread.

-- 
Pat

Re: Texinfo 7.0.92 pretest on other platforms

[Bruno Haible]

The compilation succeeds, and "make check" has all tests pass on:
* Linux:
  - Ubuntu 22.04
  - Debian 9.1
  - Debian 12
  - OpenSUSE Leap 15.5
  - Slackware 15
  - Manjaro 17 (both in 32-bit and 64-bit mode)
* Alpine Linux 3.14
* GNU/Hurd
* macOS 12.5
* FreeBSD 13.2
* OpenBSD 7.2
* AIX 7.1 and 7.3.1 (both in 32-bit and 64-bit mode), after working around
  https://lists.gnu.org/archive/html/bug-texinfo/2023-09/msg00039.html
* Solaris 10 and 11.4 (both in 32-bit and 64-bit mode)
* Solaris 11 OmniOS (both in 32-bit and 64-bit mode)
* Solaris 11 OpenIndiana (both in 32-bit and 64-bit mode)
* Cygwin 2.9.0 (in 64-bit mode)

Bruno

Re: Texinfo 7.0.92 pretest on NetBSD 9.0

[Bruno Haible]

On NetBSD 9.0, with a GNU libiconv 1.0 installed, I see this build failure:

$ gmake
...
/bin/sh ../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
-I../../../../../../tp/Texinfo/XS/gnulib/lib -I../.. -Wno-cast-qual 
-Wno-conversion -Wno-float-equal -Wno-sign-compare -Wno-undef 
-Wno-unused-function -Wno-unused-parameter -Wno-float-conversion 
-Wimplicit-fallthrough -Wno-pedantic -Wno-sign-conversion -Wno-type-limits 
-Wno-unsuffixed-float-constants  -MT libgnu_la-striconveh.lo -MD -MP -MF 
.deps/libgnu_la-striconveh.Tpo -c -o libgnu_la-striconveh.lo `test -f 
'striconveh.c' || echo 
'../../../../../../tp/Texinfo/XS/gnulib/lib/'`striconveh.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. 
-I../../../../../../tp/Texinfo/XS/gnulib/lib -I../.. -Wno-cast-qual 
-Wno-conversion -Wno-float-equal -Wno-sign-compare -Wno-undef 
-Wno-unused-function -Wno-unused-parameter -Wno-float-conversion 
-Wimplicit-fallthrough -Wno-pedantic -Wno-sign-conversion -Wno-type-limits 
-Wno-unsuffixed-float-constants -MT libgnu_la-striconveh.lo -MD -MP -MF 
.deps/libgnu_la-striconveh.Tpo -c 
../../../../../../tp/Texinfo/XS/gnulib/lib/striconveh.c  -fPIC -DPIC -o 
.libs/libgnu_la-striconveh.o
In file included from 
../../../../../../tp/Texinfo/XS/gnulib/lib/striconveh.c:29:0:
./unistr.h:21:10: fatal error: unitypes.h: No such file or directory
 #include "unitypes.h"
  ^~~~
compilation terminated.
*** Error code 1

Stop.
make[7]: stopped in /home/bruno/texinfo-7.0.92/build/tp/Texinfo/XS/gnulib/lib


In the scope of the main configure.ac, everything is fine: the top-level
build/Makefile has
  LIBUNISTRING_UNICASE_H = unicase.h
  LIBUNISTRING_UNICTYPE_H = unictype.h
  LIBUNISTRING_UNINORM_H = uninorm.h
  LIBUNISTRING_UNITYPES_H = unitypes.h
  LIBUNISTRING_UNIWIDTH_H = uniwidth.h
and thus all necessary .h files are generated in the build/gnulib/lib/ dir.

However, in the scope of the tp/Texinfo/XS/configure.ac, there is a problem:
* The build/tp/Texinfo/XS/Makefile has
LIBUNISTRING_UNICONV_H =
LIBUNISTRING_UNISTR_H = unistr.h
LIBUNISTRING_UNITYPES_H =
LIBUNISTRING_UNIWIDTH_H =
  So only unistr.h gets generated, but unitypes.h does not. This is the
  normal behaviour when the 'libunistring' module is in use.
* But you can see from the log above that no -I option is in use that
  allows the compiler to find the *installed* .
* The 'libunistring' module puts the necessary -I options into the CPPFLAGS
  variable, as documented in
  
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/libunistring.m4;h=15702811764c2812ad5fe91c2407aff0a55603b9;hb=HEAD
* But in build/tp/Texinfo/XS/config.status the value of the CPPFLAGS
  variable is empty.

The origin of the bug is here:
$ grep -n CPPFLAGS= tp/Texinfo/XS/configure.ac /dev/null 
tp/Texinfo/XS/configure.ac:100:  CPPFLAGS=$PERL_EXT_CPPFLAGS
tp/Texinfo/XS/configure.ac:152:CPPFLAGS=$PERL_EXT_CPPFLAGS

Both of these statements throw away the -I options that the configuration
previously had put there.

Bruno



netbsd90-logs.tar.gz
Description: application/compressed-tar

Re: Texinfo 7.0.92 pretest on CentOS Stream 9

[Bruno Haible]

On CentOS Stream 9, "make check" fails with 52 test failures.

Find attached the log files.



centos9-logs.tar.gz
Description: application/compressed-tar

Re: Texinfo 7.0.92 pretest on CentOS 8-stream

[Bruno Haible]

On CentOS 8-stream, I still see this test failure:

FAIL: different_encodings.sh

Already reported in
https://lists.gnu.org/archive/html/bug-texinfo/2023-08/msg00053.html

Last time, you wrote:
> Even though there is
> a stub for Unicode::Collate, the tests will not all pass without it.
> "configure" prints a warning about index sorting so users should not be
> too surprised if the tests fail.

So, as I understand it, this test failure will remain.

Bruno

Re: Texinfo 7.0.92 pretest on AIX 7.3.1

[Bruno Haible]

On AIX 7.3.1, I see a compilation error:


/opt/freeware/bin/gcc -maix64 -DHAVE_CONFIG_H -I. -I../../../gnulib/lib 
-I../..   -I/home/haible/prefix64/include -Wall -D_THREAD_SAFE  -Wno-cast-qual 
-Wno-conversion -Wno-float-equal -Wno-sign-compare -Wno-undef 
-Wno-unused-function -Wno-unused-parameter -Wno-float-conversion 
-Wimplicit-fallthrough -Wno-pedantic -Wno-sign-conversion -Wno-type-limits 
-Wno-unsuffixed-float-constants -g -O2 -MT libgnu_a-argz.o -MD -MP -MF 
.deps/libgnu_a-argz.Tpo -c -o libgnu_a-argz.o `test -f 'argz.c' || echo 
'../../../gnulib/lib/'`argz.c
In file included from ./stddef.h:80,
 from ./string.h:55,
 from ./argz.h:26,
 from ../../../gnulib/lib/argz.c:21:
/opt/freeware/lib/gcc/powerpc-ibm-aix7.3.0.0/10/include/stddef.h:426:3: error: 
conflicting types for 'max_align_t'
  426 | } max_align_t;
  |   ^~~
In file included from ./string.h:55,
 from ./argz.h:26,
 from ../../../gnulib/lib/argz.c:21:
./stddef.h:70:14: note: previous declaration of 'max_align_t' was here
   70 | typedef long max_align_t;
  |  ^~~
make: 1254-004 The error code from the last command is 1.


This is already fixed by gnulib commit
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=17c85713388407841f5c9978ecb3ccaf34ef76f1
Interestingly, texinfo/tp/Texinfo/XS/gnulib/lib/stddef.in.h has the fix
but texinfo/gnulib/lib/stddef.in.h does not.

I would have expected that you have a policy regarding which gnulib
version to use (maybe the newest one, one week before release?
or one of the stable branches [1]?), and am surprised to see that
two parts of the texinfo git use different policies.

Bruno

[1] https://www.gnu.org/software/gnulib/manual/html_node/Stable-Branches.html