On Sat, Jan 17, 2026 at 06:15:04PM +0100, Bruno Haible wrote:
> Gavin Smith wrote:
> > > What are the values of
> > > HAVE_DECL_PROGRAM_INVOCATION_SHORT_NAME
> > > and
> > > HAVE_DECL_PROGRAM_INVOCATION_NAME
> > > in config.h ? If you have several config.h files, can you look in each of
> > > them,
> > > and which config.h file is being actually used?
> >
> > The problem seems to have been that the config.h.in file was not updated
> > when the gnulib module was imported.
> >
> > In tta/config.log, there were these lines:
> >
> > configure:31570: checking whether program_invocation_name is declared
> > configure:31570: result: yes
> > configure:31585: checking whether program_invocation_short_name is declared
> > configure:31585: x86_64-linux-gnu-gcc -c -D_REENTRANT -D_GNU_SOURCE
> > -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include
> > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 conftest.c >&5
> > configure:31585: $? = 0
> > configure:31585: result: yes
> >
> > tta/C/config.h did not have either definition in it.
> >
> > So I suspected that config.h.in was out of date (even though it had a time
> > stamp
> > from today).
>
> I've never seen such a behaviour (configure updated but config.h.in not
> updated)
> in the GNU Build System.
Could it be because config.h.in is in a subdirectory? In tta/configure.ac there
is:
AC_CONFIG_HEADERS([C/config.h])
I thought it was a bit strange for the code in tta/gnulib to be using
tta/C/config.h as an include file (-I../../C appears on the compiler
command line so it is found). The rules to rebuild "C/config.h" appear
in tta/C/Makefile:
$(srcdir)/config.h.in: $(am__configure_deps)
$(AM_V_GEN)($(am__cd) $(top_srcdir) && $(AUTOHEADER))
$(AM_V_at)rm -f stamp-h1
$(AM_V_at)touch $@
It seems that this may easily not run if make does not run in that
subdirectory early enough.
> > I ran "./autogen.sh" at the top-level of the sources. After that,
> > tta/C/config.h.in had the templates for HAVE_DECL_PROGRAM_INVOCATION_NAME
> > and
> > HAVE_DECL_PROGRAM_INVOCATION_SHORT_NAME.
>
> Hmm. Maybe the bug is in 'autoreconf' that your autogen.sh script invokes?
Running autogen.sh fixed the problem, so I doubt the bug is there.
> config.h.in is a generated file. If generated files are stored in version
> control, it leads to
> - a modified file shown by "git status",
> - frequent merge conflicts when merging between branches.
Ok, thanks. If the rule to run "autoheader" will run reliably, there
would be no benefit in tracking it.
