[libvirt] [PATCH 0/2] build: fix CI builds
Fix CI builds broken by commit 5bdcef13. While doing so I noticed more unused variables, which are removed by patch1. Jim Fehlig (2): build: remove unused variables from virt-driver-libxl.m4 libxl: fallback to lib probe if pkgconfig file not found m4/virt-driver-libxl.m4 | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) -- 2.18.0
Signed-off-by: Jim Fehlig <jfehlig@suse.com> --- m4/virt-driver-libxl.m4 | 3 --- 1 file changed, 3 deletions(-) diff --git a/m4/virt-driver-libxl.m4 b/m4/virt-driver-libxl.m4 index 70c5c59e6a..422ff27022 100644 --- a/m4/virt-driver-libxl.m4 +++ b/m4/virt-driver-libxl.m4 @@ -34,9 +34,6 @@ AC_DEFUN([LIBVIRT_DRIVER_CHECK_LIBXL], [ LIBXL_FIRMWARE_DIR=$($PKG_CONFIG --variable xenfirmwaredir xenlight) LIBXL_EXECBIN_DIR=$($PKG_CONFIG --variable libexec_bin xenlight) - old_LIBS="$LIBS" - old_CFLAGS="$CFLAGS" - LIBXL_CFLAGS="$LIBXL_CFLAGS $LIBXL_API_VERSION" dnl If building with libxl, use the libxl utility header and lib too -- 2.18.0
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
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>
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
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
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
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).
participants (4)
-
Andrea Bolognani -
Jim Fehlig -
Laine Stump -
Michal Privoznik