Re: trying to build devel/gdb from 2015Q2 ... wrong autoconf version

[Thomas Klausner <wiz%NetBSD.org@localhost>]

On Fri, Aug 14, 2015 at 02:49:44PM +0200, Thomas Orgis wrote:
> I was trying to build devel/gdb (actually to debug another build
> failure where devel/boost-headers enters some endless loop in conftest
> with gcc-5.2), and get stuck here:
> 
> => Tool dependency libtool-base>=2.2.6bnb3: found libtool-base-2.4.2nb9
> => Tool dependency autoconf>=2.50: found autoconf-2.69nb6
> => Tool dependency nbpatch-[0-9]*: found nbpatch-20100124
> => Full dependency python27>=2.7.1nb2: found python27-2.7.10
> => Full dependency ncurses>=5.4nb1: found ncurses-5.9nb4
> ===> Overriding tools for gdb-7.9nb1
> ===> Extracting for gdb-7.9nb1
> ===> Patching for gdb-7.9nb1
> => Applying pkgsrc patches for gdb-7.9nb1
> ===> Creating toolchain wrappers for gdb-7.9nb1
> ===> Configuring for gdb-7.9nb1
> WARNING: 'aclocal' is missing on your system.  You should only need it if

That's weird, for Linux pkgsrc adds aclocal to tools.

>          you modified 'acinclude.m4' or 'configure.ac'.  You might want
>          to install the Automake and Perl packages.  Grab them from
>          any GNU archive site.
> configure.ac:23: error: Please use exactly Autoconf 2.64 instead of 2.69.
> ../../config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from...
> configure.ac:23: the top level

This is probably a followup problem from the previous.

Looking at the pkgsrc package and patches, I don't see a reason for
the whole Linux block in the Makefile -- try removing it and see if
that works.

> First of all … why is autoconf even needed? I though pkgsrc policy was
> to patch the resulting configure, not configure.ac? As there is no
> autoconf-2.64 in pkgsrc, I wonder what the correct way out of this is.
> Blindly patch things to make gdb accept 2.69? Avoid running autoconf at
> all? Go to the streets and demand an end to autotools version terror?

It depends -- if the diffs are too huge we sometimes depend on the
autotools during build, but usually we directly modify Makefile.in etc.
 Thomas