[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Unable to build staging-4.9 on RHEL6



>>> On 27.08.18 at 13:30, <netwiz@xxxxxxxxx> wrote:
> On Monday, 27 August 2018 8:36:50 PM AEST Jan Beulich wrote:
>> >>> On 27.08.18 at 12:03, <netwiz@xxxxxxxxx> wrote:
>> > On Monday, 27 August 2018 6:32:17 PM AEST Jan Beulich wrote:
>> >> >>> On 24.08.18 at 04:56, <netwiz@xxxxxxxxx> wrote:
>> >> > When trying to build both xen and qemu-xen from the staging-4.9
>> >> > branches, I'm running into issues compiling.
>> >> > 
>> >> > Errors start with:
>> >> > 
>> >> > BUILDSTDERR: sse.c: In function 'simd_test':
>> >> > BUILDSTDERR: sse.c:319: error: subscripted value is neither array nor
>> >> > pointer
>> >> 
>> >> That's the x86 insn emulator test harness afaict, which doesn't get
>> >> built unless you explicitly ask for it. Why are you building it? It's
>> >> well known that it requires a new enough compiler (and the bar will
>> >> raise with AVX512 support, which is in the works).
>> > 
>> > Hi Jan,
>> > 
>> > I don't specifically enable any testing (that I'm aware of).
>> > 
>> > The current SPEC file that I'm using is at:
>> > https://git.crc.id.au/netwiz/xen49/src/devel/SPECS/xen49.spec 
>> > 
>> > Essentially it boils down to:
>> > ./configure --enable-systemd --prefix=/usr --enable-xsmpolicy
>> > %{?enable_ocaml}
>> > \
>> > 
>> >   --libdir=%{_libdir} --enable-efi --disable-qemu-traditional \
>> >   --with-extra-qemuU-configure-args="--enable-spice --enable-usb-redir"
>> > 
>> > (cd xen; make defconfig; sed -i 's/# CONFIG_LIVEPATCH is not set/
>> > CONFIG_LIVEPATCH=y/g' .config; make oldconfig)
>> > 
>> > export XEN_DOMAIN=xen.crc.id.au
>> > make %{?_smp_mflags} %{?efi_flags} dist
>> 
>> It's this last step which is of interest afaict; how you configure
>> things does not seem to matter. The dist target implies building
>> dist-tools, which in turn has install-tools as a dependency. Most
>> of the sub-directories under tools/tests/ have an empty
>> install target in their makefiles though, which means nothing is
>> going to be done when entering the respective directories.
> 
> This is actually interesting.
> 
> I tried originally doing a 'make build', then 'make DESTDIR=%{buildroot} 
> install' - however I found that this didn't produce any EFI binaries in /boot/
> efi/efi/$EFI_VENDOR/ like the 'make dist' option does.
> 
> This seemed to persist across all versions (4.6 - 4.10) hence the path that I 
> had taken.
> 
> Should this then be a part of fixing why no EFI binaries exist in the make 
> build / make install method, and not trying to fix a test as a side effect of 
> having to use 'make dist'?

Hmm - "make build" surely doesn't put anything anywhere outside the
build tree. At least I very much hope it doesn't. "make dist" and
"make install", otoh, ought to match in this respect though: Both
should install files into their dedicated places. After all

install: $(TARGS_INSTALL)

and

dist: $(TARGS_DIST) dist-misc
dist-%: install-%

But for me all of this is pure theory only anyway, as I never use any
of these targets.

Considering that xen.gz and xen.efi installation are don by the same
rule, quite a bit depends on whether you observe the two variants of
make invocation to differ in more that what lands in 
/boot/efi/efi/$EFI_VENDOR/, in particular whether within the build
tree xen/xen.efi consistently appears. If both produce it, the
difference must be contained in xen/Makefile's _install rule. And don't
forget that putting _anything_ in /boot/efi/efi/$EFI_VENDOR/ is meant
as a courtesy to developers only anyway. Distributions should not
depend on this part; their boot loader setup should instead copy
whatever is necessary into /boot/efi/... (from, in the xen.efi case,
whatever EFI_DIR resolves to).

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.