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@suse.com>
---
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
+ if test "x$with_libxl" = "xno" ; then
+ with_libxl="$old_with_libxl"
+
+ save_CFLAGS="$CFLAGS"
+ CFLAGS="$CFLAGS $LIBXL_API_VERSION"
+ LIBVIRT_CHECK_LIB([LIBXL], [xenlight], [libxl_cpupool_cpuadd_cpumap], [libxl.h], [fail="1"])
+ CFLAGS="$save_CFLAGS"
+
+ if test $fail = 1; then
+ AC_MSG_ERROR([You must install the libxl Library from Xen >= 4.6 to compile libxenlight driver with -lxl])
+ fi
+ fi
+
+ if test "$with_libxl" = "yes"; then
LIBXL_CFLAGS="$LIBXL_CFLAGS $LIBXL_API_VERSION"
dnl If building with libxl, use the libxl utility header and lib too
--
2.18.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
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@suse.com> > --- > 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 Michal <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> -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, 2018-09-20 at 08:30 +0200, Michal Privoznik wrote:
> On 09/19/2018 08:59 PM, Jim Fehlig wrote:
> > + 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? :-(
We're just re-introducing code that was recently removed with
5bdcef13d135: before that, it had been there for a very long time,
so six-ish more months are hardly going to make a difference.
> <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>
We'd have to add something like
%if %{with_libxl} && 0%{?fedora} < 29
BuildRequires: xen-runtime
%endif
to libvirt.spec for that to work, and at that point you're just
exchanging one workaround for another... Might as well go for the
one that doesn't require users and CI workers to install extra
packages.
--
Andrea Bolognani / Red Hat / Virtualization
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
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@suse.com> >> --- >> 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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 09/20/2018 04:13 PM, Jim Fehlig wrote: > On 9/20/18 12:30 AM, Michal Privoznik wrote: >> <snip/> > > 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 :-). This is an urban legend. Libvirt has no bugs! :-P Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 09/20/2018 10:40 AM, Michal Privoznik wrote: > On 09/20/2018 04:13 PM, Jim Fehlig wrote: >> On 9/20/18 12:30 AM, Michal Privoznik wrote: >>> <snip/> >> 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 :-). > This is an urban legend. Libvirt has no bugs! :-P "Alternate Functionality" On a more serious note - yeah, it turns out that just putting in a workaround often ends up being much simpler than trying to coordinate a fix with the other party (assuming they even agree there is a problem). -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2026 Red Hat, Inc.