On Wed, Oct 28, 2020 at 12:45 PM Jannick <thirdedition@xxxxxxx> wrote: > > On Tue, 27 Oct 2020 13:59:21 +0100, Jannick wrote: > > If the system makes configure read in a config.site script, then > > > > 36: autoupdating AC_OBSOLETE FAILED (tools.at:1342) > > > > because the comparison of config.log is not prepared to see the additional > > line in config.log > > > > configure: loading site script /etc/config.site > > > > Here the relevant output snip when running " make check > > TESTSUITEFLAGS='-x -d -v 36' " on my system with config.site: > > [...] > > ++ ./configure > > --- - 2020-10-27 13:42:15.389259100 +0100 > > +++ /c/autotools/autoconf/tests/testsuite.dir/at-groups/36/stdout > > 2020-10-27 13:42:15.288410800 +0100 > > @@ -1,3 +1,4 @@ > > +configure: loading site script /etc/config.site > > dst=dst src=src > > configure: creating ./config.status > > Far cleaner solution: simply pass CONFIG_SITE=\"\" to the first argument of > AT_CHECK_CONFIGURE and leave configure_options alone. I'm 95% sure the testsuite should block external config.site settings from being visible to *any* of the configure runs it does. The only reason I can think of, why it might *not* be appropriate to make that change, is if there's some unusual environment where a bunch of config.site settings are necessary to make the C compiler work at all, and we could tell people using those environments to provide a wrapper script instead. However, we can't do this unconditionally in AT_CHECK_CONFIGURE, because some tests set CONFIG_SITE themselves and expect AT_CHECK_CONFIGURE to pick it up. I'll think about how to do it properly. zw
