spurious change regenerating gdb/config.in?
Maciej W. Rozycki
macro@imgtec.com
Wed Oct 19 15:55:00 GMT 2016
On Wed, 19 Oct 2016, John Baldwin wrote:
> > diff --git c/gdb/config.in w/gdb/config.in
> > index c82a5b4..3790d10 100644
> > --- c/gdb/config.in
> > +++ w/gdb/config.in
> > @@ -453,12 +453,12 @@
> > /* Define to 1 if your system has struct lwp. */
> > #undef HAVE_STRUCT_LWP
> >
> > -/* Define to 1 if `struct ptrace_lwpinfo' is a member of `pl_tdname'. */
> > -#undef HAVE_STRUCT_PTRACE_LWPINFO_PL_TDNAME
> > -
> > /* Define to 1 if `struct ptrace_lwpinfo' is a member of `pl_syscall_code'. */
> > #undef HAVE_STRUCT_PTRACE_LWPINFO_PL_SYSCALL_CODE
> >
> > +/* Define to 1 if `struct ptrace_lwpinfo' is a member of `pl_tdname'. */
> > +#undef HAVE_STRUCT_PTRACE_LWPINFO_PL_TDNAME
> > +
> > /* Define to 1 if your system has struct reg in <machine/reg.h>. */
> > #undef HAVE_STRUCT_REG
> >
> >
> > This is with pristine FSF autoconf 2.64. I suspect this is
> > just because the config.in in master was generated by some
> > other autoconf version. To confirm, does anyone else
> > see this?
>
> I don't see this, but feel free to fix. It is likely my fault somehow as I
> added the associated check. I had used a pristine FSF autoconf (built and
> installed to a custom prefix to avoid it using any other autoconf), so I'm
> not sure why it is different.
FWIW I can reproduce the phenomenon and I can see the ordering of these
macros throughout this file being alphabetic by name (with the exception
of some stuff inserted with AH_VERBATIM), so it looks to me like such
regeneration is indeed due, though I'd consider the issue very minor.
Maciej
More information about the Gdb-patches
mailing list