I got # /export/gnu/src/gcc/gcc/configure x86_64-linux configure: warning: x86_64-linux: invalid host type The problem is /usr/share/autoconf-2.13/acgeneral.m4 has changequote(, )dnl if test -n "`echo $ac_option| sed 's/[-a-z0-9.]//g'`"; then changequote([, ])dnl AC_MSG_WARN($ac_option: invalid host type) fi which means '_' can't be the part of a valid host type.
Does "configure" fail too without an arch argument?
Configure never fails. It just complains. If you don't provide an arch argument, it won't complain. The simple fix is to change if test -n "`echo $ac_option| sed 's/[-a-z0-9.]//g'`"; then to if test -n "`echo $ac_option| sed 's/[-a-z0-9._]//g'`"; then ^
RHEL 4 A3 has the same problem.
Is current autoconf failing to produce configure scripts that handle x86_64, or are we distributing some software that has this problem due to its being packaged with an older autoconf?
It is a warning, not a fatal error. This patch --- acgeneral.m4 2004-02-15 03:19:59.000000000 -0800 +++ acgeneral.m4 2004-08-20 07:42:35.677767934 -0700 @@ -552,7 +552,7 @@ changequote([, ])dnl *) changequote(, )dnl - if test -n "`echo $ac_option| sed 's/[-a-z0-9.]//g'`"; then + if test -n "`echo $ac_option| sed 's/[-a-z0-9._]//g'`"; then changequote([, ])dnl AC_MSG_WARN($ac_option: invalid host type) fi fixes it.
Is current autoconf failing to produce configure scripts that handle x86_64 without warnings, or are we distributing some software that has this problem due to its being packaged with an older autoconf? It is not clear to me if this is an autoconf problem or a problem with other software's autotooled packaging.
Created attachment 102930 [details] A testcase [hjl@gnu-64 autoconf]$ make autoconf-2.13 ./configure x86_64-linux configure: warning: x86_64-linux: invalid host type loading cache ./config.cache configure: error: can not find install-sh or install.sh in . ./.. ./../.. make: *** [all] Error 1 The warning configure: warning: x86_64-linux: invalid host type shouldn't be there.
Would it be possible for the software in question to be migrated to the current autoconf 2.5 tree? The autoconf package's "autoupdate" utility may be especially helpful for this. I do not believe the autoconf213 tree is maintained upstream, and I am not convinced we should take over maintenance of 2.1 given the feature similarities between 2.1 and 2.5 (the latter of which *is* under active development).
It is just a warning and doesn't affect outputs. It is up to you to decide if you want to apply the patch or not.
autoconf213 is "frozen" for anything but critical bugs. If you need help porting older software to the current autoconf, I would be happy to answer any specific problems you might have. You may also contact the <autoconf> mailing list for assistance. Thanks.