On Mon, Oct 10, 2022 at 11:01 AM Warner Losh <i...@bsdimp.com> wrote:
> > > On Mon, Oct 10, 2022 at 1:13 AM Thomas Huth <th...@redhat.com> wrote: > >> On 10/10/2022 08.18, Dennis Clarke wrote: >> > >> > On FreeBSD 14.0 CURRENT amd64 everything seems to go swimmingly until : >> > >> > [5679/6848] Compiling C object >> libqemu-arm-bsd-user.fa.p/bsd-user_mmap.c.o >> > [5680/6848] Compiling C object >> libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o >> > FAILED: libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o >> > /usr/bin/cc -m64 -mcx16 -Ilibqemu-arm-bsd-user.fa.p -I. -I.. >> -Itarget/arm >> > -I../target/arm -I../common-user/host/x86_64 -I../bsd-user/include >> > -Ibsd-user/freebsd -I../bsd-user/freebsd -I../bsd-user/host/x86_64 >> > -Ibsd-user -I../bsd-user -I../bsd-user/arm -Iqapi -Itrace -Iui >> -Iui/shader >> > -I/usr/local/include -I/usr/local/include/glib-2.0 >> > -I/usr/local/lib/glib-2.0/include -fcolor-diagnostics -Wall >> -Winvalid-pch >> > -std=gnu11 -O0 -g -iquote . -iquote /opt/bw/build/qemu -iquote >> > /opt/bw/build/qemu/include -iquote /opt/bw/build/qemu/tcg/i386 -pthread >> > -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE >> -Wstrict-prototypes >> > -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes >> > -fno-strict-aliasing -fno-common -fwrapv -Wold-style-definition >> > -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self >> > -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels >> > -Wexpansion-to-defined -Wno-initializer-overrides >> -Wno-missing-include-dirs >> > -Wno-shift-negative-value -Wno-string-plus-int >> -Wno-typedef-redefinition >> > -Wno-tautological-type-limit-compare -Wno-psabi >> > -Wno-gnu-variable-sized-type-not-at-end -fstack-protector-strong -m64 >> -g -O0 >> > -fno-builtin -fPIE -DNEED_CPU_H >> > '-DCONFIG_TARGET="arm-bsd-user-config-target.h"' >> > '-DCONFIG_DEVICES="arm-bsd-user-config-devices.h"' -MD -MQ >> > libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o -MF >> > libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o.d -o >> > libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o -c ../bsd-user/signal.c >> > In file included from ../bsd-user/signal.c:27: >> > In file included from ../bsd-user/host/x86_64/host-signal.h:14: >> > In file included from /usr/include/vm/pmap.h:92: >> > /usr/include/machine/pmap.h:452:2: error: fields must have a constant >> size: >> > 'variable length array in structure' extension will never be supported >> > PV_CHUNK_HEADER >> > ^ >> > /usr/include/machine/pmap.h:448:12: note: expanded from macro >> 'PV_CHUNK_HEADER' >> > uint64_t pc_map[_NPCM]; /* bitmap; 1 = free >> */ \ >> > ^ >> > /usr/include/machine/pmap.h:456:2: error: fields must have a constant >> size: >> > 'variable length array in structure' extension will never be supported >> > PV_CHUNK_HEADER >> > ^ >> > /usr/include/machine/pmap.h:448:12: note: expanded from macro >> 'PV_CHUNK_HEADER' >> > uint64_t pc_map[_NPCM]; /* bitmap; 1 = free >> */ \ >> > ^ >> > 2 errors generated. >> > ninja: build stopped: subcommand failed. >> > gmake[1]: *** [Makefile:165: run-ninja] Error 1 >> > gmake[1]: Leaving directory '/opt/bw/build/qemu/build' >> > gmake: *** [GNUmakefile:11: all] Error 2 >> > >> > phobos# >> > >> > Is there a trivial patch ? Or perhaps try again using GCC and not >> LLVM/Clang? >> >> I'm not using FreeBSD, so no real clue, but this pretty much sounds like >> _NPCM is not properly defined by your system headers anymore, so I assume >> this is a problem on the FreeBSD side ... I'd suggest to report it on the >> FreeBSD mailing list. >> > > Actually, it is properly defined. The real problem is that it depends on > howmany, which is defined > in sys/param.h, which isn't included in sys/_pv_entry.h, leading to the > problem. This makes it look > like a variable length array which compilers hate in this context. > > diff --git a/bsd-user/host/x86_64/host-signal.h > b/bsd-user/host/x86_64/host-signal.h > index 47ca19f8814..32ac4e41803 100644 > --- a/bsd-user/host/x86_64/host-signal.h > +++ b/bsd-user/host/x86_64/host-signal.h > @@ -9,6 +9,7 @@ > #ifndef X86_64_HOST_SIGNAL_H > #define X86_64_HOST_SIGNAL_H > > +#include <sys/param.h> > #include <sys/ucontext.h> > #include <machine/trap.h> > #include <vm/pmap.h> > > fixes it. It's unclear to me if this should be added to sys/_pv_entry.h > (this was just committed to > FreeBSD in the last week), or if I need to upstream this patch. > I posted a patch here (i386 needed it too). I also fixed it in FreeBSD, but the breakage was around for long enough we kinda need both. I'll submit a pull request if somebody else doesn't beat me to it. :). Warner
