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.
> 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?
I'm always using a sequence of commands, such as
aclocal -I m4 \
&& autoconf \
&& automake --add-missing --copy \
&& rm -rf autom4te.cache
> I see we do not trck config.h.in in git. I wonder if there is any downside
> in tracking this file.
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.
Bruno
