Build system mess in stubdom

[Andrew Cooper <andrew.cooper3@citrix.com>]

Hello,

I'm trying to investigate why stubdom/ is fatally failing now with a
rebuilt ArchLinux container (GCC 14).

It is ultimately:

> ../../../../../newlib-1.16.0/newlib/libc/reent/signalr.c:61:14: error:
> implicit declaration of function ‘kill’; did you mean ‘_kill’?
> [-Wimplicit-function-declaration]
>    61 |   if ((ret = _kill (pid, sig)) == -1 && errno != 0)
>       |              ^~~~~
> make[7]: *** [Makefile:483: lib_a-signalr.o] Error 1

which doesn't make sense, but is a consequence of the ifdefary in
newlib/libc/include/_syslist.h

However, we've got problems ahead of that.

First of all, with:

[user@89aef714763e build]$ ./configure --disable-xen --disable-tools
--disable-docs
<snip>
Will build the following stub domains:
  xenstore-stubdom
  xenstorepvh-stubdom
configure: creating ./config.status
config.status: creating ../config/Stubdom.mk

both a top level `make` and `make stubdom` end up building all of tools,
contrary to comments in the makefile.

`make build-stubdom` does (AFAICT) only build stubdom.

However, building just the xenstore stubdoms recursively builds all of
tools/libs/ even though only some are needed.  This includes libxl which
then recurses further to get tools/libacpi, and libxenguest which
recurses further to get libelf from Xen.

What I can't figure out is why xenstore ends up pulling in all of newlib.

Semi-irrespective, there's no way we can keep on bodging newlib to
compile with newer compilers.  There's a whole bunch of other warnings
(strict-prototypes, dangling-else, maybe-uninitialized, unused-function,
pointer-sign, unused-variable) primed ready to cause breakage in any
environment which makes these error by default.

I'm going to be making ArchLinux non-blocking because it is a rolling
distro, but we also can't do nothing here.

~Andrew