The config.sub and config.guess files need to be updated before generating another release. These can be found at: http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.guess http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.sub Thank you. Reproducible: Always Steps to Reproduce: ./configure on an unsupported system (DragonFly)
Are these versions present in a stable release version of autoconf/automake? I don't think we're interested in distributing possibly-unstable build scripts to fix compilation on a minority system. I'd suggest patching the files downstream, as generating releases against a different version of the auto* tools will likely be a pain (at least until they're packaged for Olivier's distro). Olivier, you're the one that'll be doing the release, so I guess it's up to you ^_^.
Unless we receive a bug report that relates directly to the version of the toolchain we use, I see no reason to update or change the existing tools. What would buy us these new versions? What bug in the current used versions affects Xfce?
From config.guess I see the date from: timestamp='2005-05-27' After looking on the gnu site, it doesn't look like there has been a release of auto* since then. The best plan may be to copy these files into the appropriate directory they get picked up from (probably under /usr/share somewhere). This isn't a programming bug, but a build problem. Updating these will provide more support for other systems (DragonFlyBSD among them) and make sure you have the most up to date config.h values for all systems.
I repeat, using unreleaed build files in our release tarballs is a bad idea, and manually copying files, overwriting those in Olivier's release build machine sounds like an equally bad idea. Again, I'll suggest that you patch these in your downstream packages until GNU makes official releases containing the proper support. (You obviously don't know all that much about the autotools if you think that doing this ill-advised upgrade will "make sure you have the most up to date config.h values for all systems". The config.h values are generated with autoheader, and with m4 macros that are unrelated to the two files you're talking about.)
Moving invalid bugs to the /dev/null product.