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.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris
