On Sun, Apr 13, 2025 at 07:41:59PM +0200, Santiago Vila wrote: > Hello. > > In this version, I still need the attached patch to make the build > reproducible: > > https://reproducible-builds.org/
Thanks; more comments on it below, although I'm inclined to include it or something similar shortly. > > Also, running autoreconf produces funny results: > > configure.ac:155: the top level > configure.ac:155: warning: gl_TYPE_WINT_T_PREREQ is m4_require'd but not > m4_defun'd > m4/gnulib-comp.m4:855: M4_INIT is expanded from... > configure.ac:155: the top level > configure.ac:155: warning: gl_PTHREADLIB is m4_require'd but not m4_defun'd > m4/sched_yield.m4:9: gl_FUNC_SCHED_YIELD is expanded from... > m4/gnulib-comp.m4:855: M4_INIT is expanded from... > configure.ac:155: the top level > configure.ac:155: warning: gl_PTHREADLIB is m4_require'd but not m4_defun'd > m4/yield.m4:9: gl_YIELD is expanded from... > m4/gnulib-comp.m4:855: M4_INIT is expanded from... > configure.ac:155: the top level > configure:9783: error: possibly undefined macro: gl_ANYTHREADLIB_EARLY > If this token and others are legitimate, please use m4_pattern_allow. > See the Autoconf documentation. > configure:20172: error: possibly undefined macro: gl_PTHREADLIB > configure:20285: error: possibly undefined macro: gl_WEAK_SYMBOLS > configure:24933: error: possibly undefined macro: gl_TYPE_WINT_T_PREREQ > autoreconf: error: /usr/bin/autoconf failed with exit status: 1 Adding bug-gnulib to investigate this. Bruno, I've seen it as well; I suspect it may be related to m4 putting this in m4's configure.ac: # M4 is single-threaded; so we can optimize gnulib code by using this: gl_DISABLE_THREADS AC_DEFINE([GNULIB_REGEX_SINGLE_THREAD], [1], [Define to optimize regex.]) AC_DEFINE([GNULIB_MBRTOWC_SINGLE_THREAD], [1], [Define to optimize mbrtowc.]) AC_DEFINE([GNULIB_WCHAR_SINGLE_LOCALE], [1], [Define to optimize mbrtowc.]) right after AC_PROG_CC and M4_EARLY() (the macro created by gnulib-tool). It could be that I'm using the macros in the wrong place, or it could be a genuine issue in the behavior of the gnulib macros for short-circuiting decisions for a known-single-threaded app. > From: Vagrant Cascadian <vagr...@reproducible-builds.org> > Subject: Remove date from m4 texinfo file > Bug-Debian: https://bugs.debian.org/950419 > X-Debian-version: 1.4.18-5 > > --- a/doc/m4.texi > +++ b/doc/m4.texi > @@ -41,7 +41,7 @@ > > @copying > > -This manual (@value{UPDATED}) is for GNU M4 (version > +This manual is for GNU M4 (version > @value{VERSION}), a package containing an implementation of the m4 macro > language. My understanding is that UPDATED is set to the day the manual is built (which obviously is not reproducible). But out of curiosity - but is there a way to make the reproducible hard-code the date of the git commit into UPDATED rather than the current date? It would still be nice if the manual could include the release date (something that reproducibly gets included, no matter whether I build today or a year from now, by scraping something out of git or NEWS), which is going to be more useful than the date the manual is built. Also, I see two uses of @value{UPDATED} in m4.texi, but your patch only removed one; is the other one not an issue? $ git grep UPDATED ChangeLog-2014: * doc/m4.texinfo: UPDATED refers to the day the manual was built, doc/m4.texi:This manual (@value{UPDATED}) is for GNU M4 (version doc/m4.texi:@subtitle Edition @value{EDITION}, @value{UPDATED} -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org
