Re: [lmi] 'bullseye' vs. 'bookworm' build logs

[Vadim Zeitlin]

On Sat, 23 Oct 2021 21:15:18 +0000 Greg Chicares <greg.chicares@gmail.com> 
wrote:

GC> Should we run 'autoupdate' for wx and for xmlsoft.org libraries?
GC> Do we care if the 'mt' utility is no longer available?
GC> Is it important that building libtiff fails to find libjpeg?
GC> Does it matter if MinGW-w64-gcc emits some diagnostics for 'tif_print.c'?
GC> If the answers are all "no", then the rest of this email can be ignored.

 None of these is a serious, let alone critical, problem. But a couple of
them could perhaps be addressed just for tidiness.

GC> (1) wx submodule version [resolved--feel free to skip]

[FWIW the resolution is indeed correct]

GC> (2) anomaly in schroot mount table [feel free to skip]

 I have no choice but to skip this one because I still don't use schroot
and I think it's indeed something specific to it.

GC> (3) libxml2 autotools
GC> 
GC> ZZZ-+ cd /opt/lmi/src/lmi/third_party/libxml2
GC> ZZZ-+ NOCONFIGURE=1 ./autogen.sh
GC> [...]
GC> ZZZ-configure.ac:474: warning: The macro `AC_HEADER_STDC' is obsolete.
GC> ZZZ-configure.ac:474: You should run autoupdate.
GC> 
GC> Should we run 'autoupdate', or is it okay to ignore this?

 It's fine to ignore this, AC_HEADER_STDC continues to work for now and we
probably don't want to maintain our own patch to libxml2 just to avoid this
warning. And I don't think libxml2 would accept the change generated by
autoupdate, which is this (omitting the irrelevant change to AC_PREREQ):

---------------------------------- >8 --------------------------------------
diff --git a/configure.ac b/configure.ac
index 5b161a54..7ededa05 100644
--- a/configure.ac
+++ b/configure.ac
@@ -471,7 +471,15 @@ echo Checking headers

 dnl Checks for header files.
 AC_HEADER_DIRENT
-AC_HEADER_STDC
+m4_warn([obsolete],
+[The preprocessor macro `STDC_HEADERS' is obsolete.
+  Except in unusual embedded environments, you can safely include all
+  ISO C90 headers unconditionally.])dnl
+# Autoupdate added the next two lines to ensure that your configure
+# script's behavior did not change.  They are probably safe to remove.
+AC_CHECK_INCLUDES_DEFAULT
+AC_PROG_EGREP
+
 AC_CHECK_HEADERS([fcntl.h])
 AC_CHECK_HEADERS([unistd.h])
 AC_CHECK_HEADERS([ctype.h])
---------------------------------- >8 --------------------------------------

I.e. it basically wants you to remove AC_HEADER_STDC entirely, which might
well be a good idea by now, but who knows what kind of ancient systems
libxml2 still might have to support.

GC> ZZZ-checking for gcc option to enable C11 features... none needed
GC> ZZZ+checking for gcc option to accept ISO C89... none needed
GC> 
GC> The 'bookworm' chroot checks for a less ancient C dialect than
GC> 'bullseye', although they're using the same libxml submodule.
GC> Is this a real concern? Could a more modern autotools package
GC> in 'bookworm' explain the difference?

 Yes, absolutely. The expansion of one of the standard macros (I was too
lazy to check which one, but I could find it if you're curious) must have
changed in autoconf 2.71 used in Bookworm, explaining this.

GC> ZZZ-checking for mt... no
GC> ZZZ+checking for mt... mt
GC> 
GC> Here, it looks like 'bookworm' has lost what I think is a utility
GC> for reading magnetic tapes. I guess I'll ignore it as long as no
GC> error occurs downstream.

 I'd expect you to still have /bin/mt, which is part of cpio package that
still exists, so either it wasn't installed by default in your Bookworm
chroot due to not being needed any longer, i.e. due to a dependency change
(because I don't think you'd ever install cpio manually), or maybe it was
installed but the "alternative" link /bin/mt hasn't been created.

GC>  Validating the HTML Web pages
GC> ZZZ+make[1]: [Makefile:737: API.html] Error 1 (ignored)
GC> 
GC> One less error message with 'bookworm'. Good.

 This is a bit weird because I don't see how could this fix itself on its
own. But it's definitely not important enough to look into it.

GC> (4) wx autotools: tiff no longer finds libjpeg
GC> 
GC>  === configuring in src/tiff [...]
GC> ZZZ-checking for jpeg_read_scanlines in -ljpeg... yes
GC> ZZZ-checking jpeglib.h usability... yes
GC> ZZZ-checking jpeglib.h presence... yes
GC> ZZZ-checking for jpeglib.h... yes
GC> ZZZ+checking for jpeg_read_scanlines in -ljpeg... no
GC> ZZZ+checking jpeglib.h usability... no
GC> ZZZ+checking jpeglib.h presence... no
GC> ZZZ+checking for jpeglib.h... no
GC> 
GC> I'm not sure tiff is relevant.

 No, lmi doesn't use TIFF images support anyhow, to the best of my
knowledge, but it's still strange. What's even stranger is that we use
built-in tiff in the first place, why don't we use the system libtiff? We
could save a few CPU cycles by installing this (and other, if they're not
installed neither) libraries with their development packages.

GC> (5) wx autotools: "You should run autoupdate"
GC> 
GC> ZZZ-autoreconf: Entering directory '.'
GC> ZZZ+autoreconf: Entering directory `.'
GC>  autoreconf: configure.ac: not using Gettext
GC>  autoreconf: running: aclocal -I admin/m4
GC>  autoreconf: configure.ac: tracing
GC>  autoreconf: configure.ac: not running libtoolize: --install not given
GC> ZZZ-autoreconf: configure.ac: not using Intltool
GC> ZZZ-autoreconf: configure.ac: not using Gtkdoc
GC>  autoreconf: running: /usr/bin/autoconf
GC> ZZZ-configure.ac:21: warning: The macro `AC_HELP_STRING' is obsolete.
GC> ZZZ-configure.ac:21: You should run autoupdate.
GC> 
GC> The 'bookworm' chroot ("ZZZ-") is the one that reports this.
GC> Should we run 'autoupdate'?

 I've tried, but it died with a typically opaque error. But this could be
worth looking into, just to avoid the warnings, so I'll spend some (but not
much) more time on this a bit later.

GC> (6) a few warnings in the wx build: msw only, not linux
GC> 
GC> ZZZ+/opt/lmi/src/lmi/third_party/wx/src/tiff/libtiff/tif_print.c:100:21: 
warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 3 
has type ‘long long unsigned int’ [-Wformat=]

 I did see these and they're annoying, even though harmless. Fixing them is
not that hard, but understanding what kind of fix would the upstream prefer
is a bit more difficult. I'll try to make another effort to do it before wx
3.2.0 release as I'd like it to build without warnings.

GC> I've omitted several other warnings in 'tif_print.c'; I'm guessing
GC> that none of them affects lmi.

 No, nor even wx, as these warnings are actually in the code that wx
doesn't use at all. But they still pollute the build logs, which is why I'd
like to get rid of them.

 Regards,
VZ

pgpykA8qTzPD7.pgp
Description: PGP signature