[PATCH] libsframe: testsuite: Fix testsuite build on Solaris [PR33168]

[Alan Modra]

On Sat, Aug 30, 2025 at 11:55:50AM +0200, Rainer Orth wrote:
> Hi Alan,
> 
> >> On Fri, Aug 15, 2025 at 10:08:38AM +0200, Rainer Orth wrote:
> >>> diff --git a/libsframe/configure.ac b/libsframe/configure.ac
> >>> --- a/libsframe/configure.ac
> >>> +++ b/libsframe/configure.ac
> >>> @@ -23,7 +23,6 @@ AC_CONFIG_SRCDIR(sframe.c)
> >>>  
> >>>  AC_CANONICAL_TARGET
> >>>  
> >>> -AC_USE_SYSTEM_EXTENSIONS
> >>>  AM_INIT_AUTOMAKE
> >>>  AM_SILENT_RULES([yes])
> >>>  
> >>
> >> I'd be inclined to fix the dejagnu.h "wait" problem some other way.
> >> Maybe
> >>
> >> #define wait deja_wait
> >> #include <dejagnu.h>
> >> #undef wait
> >>
> >> in the libsframe test files that include this header.
> >
> > there is none, unfortunately.  Apart from system headers, the tests only
> > include config.h (which is also included by the libsframe code itself,
> > not only the testsuite) and sframe-api.h, which is the libsframe
> > interface, thus doesn't seem appropriate for this.
> >
> > My intention was to avoid having this snippet in 8 individual testcases,
> > thus the attempt to do this outside.
> >
> > One could, of course, introduce a new sframe-test.h or some such which
> > would only include those lines for now.  Seems a bit wasteful to me, but
> > maybe clearer.
> 
> as an afterthough, it occured to me that one might as well introduce
> such a header, moving *all* libsframe testsuite includes there together
> with the above hack.  AFAICS, the set of headers included is almost
> identical across all tests.

That sounds like the way to go.

> > I'm really uncertain if the argument about removing
> > AC_USE_SYSTEM_EXTENSIONS does hold water, though.  It bears some risk,
> > of course, but as I said, it was only introduced into binutils for an
> > obscure platform long gone, and thus carried forward to most other
> > configure.ac's.  OTOH, it's not in gdb/testsuite, libdecnumber,
> > readline, sim, and zlib, which makes me wonder even more about the
> > necessity.
> 
> Even with some sframe-test.h, I still consider the jury to be out on the
> necessity of AC_USE_SYSTEM_EXTENSIONS.  However, that should be
> evaluated separately for the whole of binutils.  The situation may be
> different there, however, since other parts of binutils most likely
> include more system-specific stuff than libsframe does.

Right.  We'd need someone with detailed knowledge of what
AC_USE_SYSTEM_EXTENSIONS does on all the various hosts where binutils
is likely to be built.  It's easy enough to see that on my linux
machine it will define _GNU_SOURCE which enables some large file
support among other things.  That conceivably changes binutils on
32-bit linux hosts, because not all directories invoke
AC_SYS_LARGEFILE in their configure.ac.  I'm not interested enough to
do the work necessary to remove AC_USE_SYSTEM_EXTENSIONS with any
confidence.

-- 
Alan Modra