On 9/20/18 12:30 AM, Michal Privoznik wrote:
On 09/19/2018 08:59 PM, Jim Fehlig wrote:
With the assumption that all Xen >= 4.6 contains a pkgconfig file for
libxenlight, commit 5bdcef13 dropped the fallback check to probe
libxenlight with LIBVIRT_CHECK_LIB. At the time it was not known that
the various Xen pkgconfig files are in the -runtime package in Fedora,
instead of the traditional -devel package. This bug [1] was fixed in
Fedora > 28, but until Fedora 28 reaches EOL we'll need to re-introduce
the fallback check.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1629643
Signed-off-by: Jim Fehlig <jfehlig@xxxxxxxx>
---
m4/virt-driver-libxl.m4 | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/m4/virt-driver-libxl.m4 b/m4/virt-driver-libxl.m4
index 422ff27022..479d9116a4 100644
--- a/m4/virt-driver-libxl.m4
+++ b/m4/virt-driver-libxl.m4
@@ -29,11 +29,31 @@ AC_DEFUN([LIBVIRT_DRIVER_CHECK_LIBXL], [
LIBXL_API_VERSION="-DLIBXL_API_VERSION=0x040500"
dnl search for libxl, aka libxenlight
- LIBVIRT_CHECK_PKG([LIBXL], [xenlight], [4.6.0])
+ old_with_libxl="$with_libxl"
+ LIBVIRT_CHECK_PKG([LIBXL], [xenlight], [4.6.0], [true])
if test "x$with_libxl" = "xyes" ; then
LIBXL_FIRMWARE_DIR=$($PKG_CONFIG --variable xenfirmwaredir xenlight)
LIBXL_EXECBIN_DIR=$($PKG_CONFIG --variable libexec_bin xenlight)
+ fi
+ dnl In Fedora <= 28, the xenlight pkgconfig file is in the -runtime package
+ dnl https://bugzilla.redhat.com/show_bug.cgi?id=1629643
+ dnl Until Fedora 28 reaches EOL, fallback to lib probe if xenlight.pc is
+ dnl not found
Le sigh. So we have to have this in for next what 6 months? :-(
ACK though
Thanks, I've pushed these.
<rant>
Sure, we can try working around broken packaging, or we can be brave
and just tell users to install yet another package if they want to have
xl driver enabled simply because they are using broken package. It's not
our bug, and we already work around plenty of other bugs for other
apps/libs.
</rant>
Nod.
Over the years my ranting about such workarounds has ebbed as they have become
commonplace throughout the stack: kernel works around hardware bugs, runtimes
work around kernel bugs, apps work around runtime bugs, ... I've also seen
workarounds for libvirt bugs :-).
Regards,
Jim
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
