On Tue, 9 Jun 2026, Sam James wrote: > diff --git a/gcc/configure.ac b/gcc/configure.ac > index 4360cb955662..88628647c881 100644 > --- a/gcc/configure.ac > +++ b/gcc/configure.ac > @@ -7545,7 +7545,9 @@ AC_SUBST(enable_host_shared) > # Enable --enable-host-pie > AC_ARG_ENABLE(host-pie, > [AS_HELP_STRING([--enable-host-pie], > - [build host code as PIE])]) > + [build host code as PIE])], > + [enable_host_pie=$enableval], > + [enable_host_pie=no]) > AC_SUBST(enable_host_pie)
I'm not convinced this change, or other similar ones where the third argument wasn't previously present, is either necessary or correct. Subsequent tests on $enable_host_pie in gcc/configure.ac only case about whether it's "yes", a case not affected by this change. While it's also AC_SUBSTed into gcc/Makefile.in, which has code ifneq ($(enable_host_shared)$(enable_host_pie),) LIBIBERTY = ../libiberty/$(LIBIBERTY_PICDIR)/libiberty.a else LIBIBERTY = ../libiberty/libiberty.a endif so that if enable_host_pie becomes "no" rather than empty in the case where the option isn't passed at all, that would seem to be treated the same as "yes". So there may be a bug that --disable-host-pie is incorrectly handled in gcc/Makefile.in, but the above change doesn't look like it would fix it; it looks like it would extend that bug to more cases. In general, in cases that do AC_SUBST(enable_host_pie) you need to look at what use is made of the substituted value, not just at the code in configure.ac. And if you want the code to be more consistent about having a third argument to AC_ARG_ENABLE whether or not it's used, maybe there should be a GCC_ENABLE_HOST_PIE or similar macro defined in config/ rather than separately using AC_ARG_ENABLE in lots of configure scripts (though that might run into needing to deal with the differences between how AC_ARG_ENABLE is used for this option in each subdirectory). Likewise for other related configure options. -- Joseph S. Myers [email protected]
