Requiring newer autoconf for X.Org packages?

[Alan Coopersmith]

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

[Keith Packard]

Alan Coopersmith <alan.coo...@oracle.com> writes:

> 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.

Yeah, GCC still uses 2.69 internally, Debian stable ships with 2.69, if
I were shipping a generated configure script, I'd be tempted to use that
too.

> 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:

Is there something keeping us from just adding _OPENBSD_SOURCE somewhere
in xorg-macros.m4 and have the affected repos use that?

--
-keith

[Alan Coopersmith]

On 8/30/22 15:40, Keith Packard wrote:
> Alan Coopersmith <alan.coo...@oracle.com> writes:
>
>> 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.
>
> Yeah, GCC still uses 2.69 internally, Debian stable ships with 2.69, if
> I were shipping a generated configure script, I'd be tempted to use that
> too.

I know 2.70 itself broke a bunch of things, but I thought 2.71 fixed them.
Are there still problems, or are people just being extra cautious after the
poor experience with 2.70?

>> 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:
>
> Is there something keeping us from just adding _OPENBSD_SOURCE somewhere
> in xorg-macros.m4 and have the affected repos use that?

I hadn't thought of doing that - it's a little more work for us up front,
but otherwise similar level of effort.

There's not a great fit for it there - I don't see any other macros that end
up making C defines - but I suppose we could add it to XORG_COMPILER_FLAGS.

[Matthieu Herrb]

On Tue, Aug 30, 2022 at 02:42:39PM -0700, Alan Coopersmith wrote:
>
> 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
>

Hi,

autoconf 2.71 complains about obsolete contructs in X.Org's
configure.ac : AC_PROG_LIBTOOL AC_PROG_CC_C99 and suggests to run
autoupdate to fix.

This will trigger a lot of new packages releases :-)

--
Matthieu Herrb

[Povilas Kanapickas]

Just a note, xserver master branch no longer contains autotools support
and we can't bump AC_PREREQ on xorg-server-21.1.x so we will need to
implement the workaround for meson anyway.

Cheers,
Povilas

[Daniel Stone]

Hi,

On Tue, 30 Aug 2022 at 22:42, Alan Coopersmith <alan.coo...@oracle.com> wrote:

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?

GPLv3 is still a huge no-go for a fair few vendors I know of. If you look around various product source drops, you can generally use shipping bash 3.2.x as a proxy for this.

I don't think this is a huge deal though; for xserver they're all using Meson + Xwayland (if at all), and for the libs they can either rebuild with older autotools (if it's still compatible), or just stick with an older version and forego the torrent of forthcoming improvements in those codebases.

Cheers,

Daniel

[Alan Coopersmith]

On 8/31/22 01:08, Matthieu Herrb wrote:
> On Tue, Aug 30, 2022 at 02:42:39PM -0700, Alan Coopersmith wrote:
>>
>> 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
>>
>
> Hi,
>
> autoconf 2.71 complains about obsolete contructs in X.Org's
> configure.ac : AC_PROG_LIBTOOL AC_PROG_CC_C99 and suggests to run
> autoupdate to fix.

Which doesn't actually work, as the calls are in xorg-macros.m4,
not actually in our configure.ac files.

> This will trigger a lot of new packages releases :-)

Many of our packages have unreleased autoconf or autogen.sh cleanup already.

[Jeremy Huddleston Sequoia]

> On Aug 30, 2022, at 14:42, Alan Coopersmith <alan.coo...@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.

[Alan Coopersmith]

On 9/12/22 22:32, Jeremy Huddleston Sequoia wrote:
>> On Aug 30, 2022, at 14:42, Alan Coopersmith <alan.coo...@oracle.com> wrote:
>> 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.

Thanks - since no one said this would be a problem for them, and since I just
broke NetBSD builds by accidentally generating the libX11-1.8.4 tarballs with
autoconf 2.69 instead of 2.71, I've opened an MR for this:

https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/187

and verified it would have stopped me making that mistake.

If there are indeed folks out there who really want a non-GPLv3 build
system, I encourage you to help with our (slowly) ongoing efforts to
convert the X.Org packages to build with the Apache-2.0 licensed meson
build system instead.