autoreconf -f -i fails for 2.1.0-rc1 with automake 1.11.6

[Bas Couwenberg]

There seems to be an issue with the old Autotools used in Debian experimental due to it having GCC 6 but not having all its reverse dependencies rebuilt for it.

The Debian package builds for GDAL 2.1.0-rc1 failed on most architectures as can been seen in the ​buildd status. autoreconf -f -i fails with:

main::scan_file() called too early to check prototype at /usr/bin/aclocal line 644.
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
libtoolize: 'AC_PROG_RANLIB' is rendered obsolete by 'LT_INIT'
main::scan_file() called too early to check prototype at /usr/bin/aclocal line 644.
configure.in:135: error: possibly undefined macro: AC_LD_SHARED
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.in:163: error: possibly undefined macro: AC_HAVE_LONG_LONG
configure.in:164: error: possibly undefined macro: AC_UNIX_STDIO_64
configure.in:217: error: possibly undefined macro: AC_CHECK_FUNC_CUSTOM
configure.in:4663: error: possibly undefined macro: AC_CHECK_FW_FUNC
autoreconf: /usr/bin/autoconf failed with exit status: 1

I haven't been able to reproduce the failure on my own systems, which seems to be caused by them using automake 1.15 instead of 1.11.6 as used on the build daemons where the failure occurs.

Most distributions (according to ​whohas) have newer automake available, so this issue seems limited to Debian experimental currently. Ubuntu precise also has automake 1.11, so is likely affected too. Since that release is ancient, I don't think we need to worry about that.

I think it's sufficient to require a newer version of automake to avoid this issue. Does that make sense to incorporate in the GDAL buildsystem?

[Even Rouault]

I'm afraid I didn't really understand how your recomandation regarding "requiring a newer version of automake" would translate concretely. GDAL autoconf stuff is quite fragile. Is the "autoreconf -f -i" really needed ? Why not just running the generated ./configure ?

Regarding Ubuntu precise, it is not so old. I guess we'd want people to still be able to build on it (I even use older systems...)

[Bas Couwenberg]

autoreconf is used to support new architectures without having to patch the buildsystem. It takes care of updating config.{guess,sub}, libtool, etc automatically.

Because typical automake is not used by GDAL, I'm not sure how requiring a minimum version would work either.

To work around the build failure with automake1.11 I've added it to the Build-Conflicts of the package to have the dependency resolution not consider it for installation. So perhaps we should leave GDAL as it is, at least until another user reports the same issue.

[Even Rouault]

Removing target milestone as it corresponds to a now closed milestone.

[Bas Couwenberg]

Let's close this as not important enough to fix, the issue doesn't affect the Debian package any more. If it affects other users, this issue can be reopened.