Requiring newer autoconf for X.Org packages?
Alan Coopersmith
alan.coopersmith at oracle.com
Tue Aug 30 21:42:39 UTC 2022
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?
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
More information about the xorg-devel
mailing list