Fix configure.ac buglet when used with autoconf 2.70

[jmarshall]

As detected in Debian bug 978835, HTSlib's ./configure fails when built with autoconf 2.70 (released in December). It is a byproduct of autoconf 2.70 being more careful about cross compilation:

*** More macros use config.sub and config.guess internally.

As a consequence of improved support for cross compilation [snip]

Using the standard $host_alias variable name in our shared library check was fun and intended to be mostly already correct if we moved to using AC_CANONICAL_HOST at the top of the configure script, but causes problems when autoconf 2.70 implicitly uses AC_CANONICAL_HOST below our check. The simple fix is to use a variable name that's not used by autoconf, as there are reasons not to move to using AC_CANONICAL_HOST just yet.

As autoconf 2.70 implicitly uses AC_CANONICAL_HOST, it requires (and its autoreconf --install installs) config.guess and config.sub. Ignore those, and ignore install-sh as well for good measure.

[jkbonfield]

Thanks for this John.

I see our Travis and Cirrus configs use autoreconf. The INSTALL file however tries to explicitly suggest doing it by hand using autoheader and autoconf. I'm guessing this is no longer workable with autoconf 2.7.0 as the changes document explicitly states using autoreconf --install. Is this true? (I note we don't have a --install and it still works though, so maybe it's getting them from elsewhere and we don't now have a requirement to use autoreconf.)

[jmarshall]

Correct. I have a second draft PR coming up that makes it “2.70-esque native”, with the recommendation that there's no point applying it until autoconf 2.70 is widespread.

[jkbonfield]

Ok thanks.

[jmarshall]

See also PR #1199, which expands on the reasons not to move to using AC_CANONICAL_HOST just yet, not until autoconf 2.70 is widespread at which point HTSlib's release-making scripts, instructions, and other infrastructure will have to learn about config.guess etc anyway.

Currently Travis/Cirrus/etc work fine because they are using autoconf 2.69 and the resulting configure script doesn't invoke any of these three support scripts. I guess we could at our leisure change the CI scripts to use autoreconf --install which will do the same thing as presently with 2.69 but hopefully start copying the support scripts and just carry on working when the CI environments update to 2.70.