Requiring newer autoconf for X.Org packages?

[Jeremy Huddleston Sequoia]

> On Aug 30, 2022, at 14:42, Alan Coopersmith <alan.coopersmith at oracle.com> wrote:
> 
> Thomas Klausner & I have been having an off-list discussion about a problem
> he had building some X.Org packages for NetBSD.
> 
> For historical reasons, the NetBSD headers hide the prototype for reallocarray()
> behind #ifdef _OPENBSD_SOURCE - while the question has been asked if this is
> still necessary now that it's widely adopted, including in the next version of
> POSIX, that's the way it is in the existing releases.  (It's not the only
> platform to do something like this - the lack of _GNU_SOURCE was reported in
> https://gitlab.freedesktop.org/xorg/lib/libxext/-/issues/4 .)
> 
> The easy solution is to use autoconf 2.70 or newer, since that release added
> _OPENBSD_SOURCE to the defines added by AC_USE_SYSTEM_EXTENSIONS:
> https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=c467efab94cd2d0331655
> 
> But currently we leave it mostly up to whoever builds the tarballs for release
> to decide what version of autoconf to use (though they in turn mostly rely on
> what their distro builder packages in the version they run), and even the latest
> xorg-server-21.1.4 tarball was built with autoconf 2.69.
> 
> We document autoconf 2.62 as the minimum release required in:
> https://www.x.org/wiki/Building_the_X_Window_System/
> and most modules have AC_PREREQ([2.60]).  If I recall correctly, a decade ago
> we didn't want to force use of autoconf 2.65 or later since some vendors were
> still uncertain at that time about those newer version being under GPLv3 - is
> that still a problem for anyone?

That was mainly a problem for me (well, Apple) for a while.  This is no longer an issue for XQuartz, so I am supportive of this change if it helps out NetBSD.

> If not, we could start bumping the AC_PREREQ to 2.70 in just the repos that
> use reallocarray, to ensure we don't accidentally ship versions that can't
> build on NetBSD - that's still a small subset of the modules we ship - only
> 11 out of 265 so far:
> 
> app/fslsfonts
> app/xauth
> app/xmodmap
> app/xrdb
> lib/libfontenc
> lib/libFS
> lib/libX11
> lib/libXext
> lib/libXfont
> lib/libXmu
> xserver
> 
> (And as much as I'd love to believe that meson will solve this for us, that
> seems unlikely in this case:
> https://github.com/mesonbuild/meson/search?q=_OPENBSD_SOURCE
> so it seems we'll have to reinvent the wheel there.)
> 
> -- 
>        -Alan Coopersmith-                 alan.coopersmith at oracle.com
>         Oracle Solaris Engineering - https://blogs.oracle.com/solaris
>