Re: Build system mess in stubdom

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

On Tue, Jul 09, 2024 at 02:49:57PM +0100, Andrew Cooper wrote:
> 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.

:-(, I never noticed that but yeah, that rules is what end up building
the tools:

    install-stubdom: mini-os-dir install-tools

So unless you use one of the build targets, the top makefile end-up
wanting to also install (or dist) the tools. I don't think we can change
that:
    dc497635d93f ("build system: make install-stubdom depend on install-tools 
again")

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

How do you make that works with `./configure --disable-tools` ? I've got
this:
    $ make build-stubdom
    <snip>
    make -C tools/include build
    ....tools/include/../../tools/Rules.mk:212: *** You have to run ./configure 
before building or installing the tools.  Stop.
    make: *** [Makefile:44: build-tools-public-headers] Error 2

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

libxl? how? Did you run `make -C stubdom xenstore-stubdom`? Or maybe you
used ./configure to select only "xenstore-stubdom"? In that later case
only the build* targets will only build stubdom, the default target as
well as dist* and install* targets will want to "install-tools" as seen
above.

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

I think it's because of these in stubdom/Makefile:
    xenstore: $(CROSS_ROOT) xenstore-minios-config.mk
    $(CROSS_ROOT): cross-newlib cross-zlib cross-libpci

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

I guess we could try to update newlib, 1.16 is from 2007 apparently, and
there's now 4.4 from last year.

Cheers,

--

Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech