diff mbox

[1/8] xen: link against xentoolcore

Message ID 1507564902-9000-2-git-send-email-ian.jackson@eu.citrix.com (mailing list archive)
State New, archived
Headers show

Commit Message

Ian Jackson Oct. 9, 2017, 4:01 p.m. UTC 
From: Anthony PERARD <anthony.perard@citrix.com>

Xen libraries 4.10 will include a new xentoolcore library, without
which xendevicemodel et al will not work.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 configure | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

Comments

Ian Jackson Oct. 9, 2017, 4:28 p.m. UTC | #1 
Ian Jackson writes ("[PATCH 1/8] xen: link against xentoolcore"):
> From: Anthony PERARD <anthony.perard@citrix.com>
> 
> Xen libraries 4.10 will include a new xentoolcore library, without
> which xendevicemodel et al will not work.

The xentoolcore library was just committed to xen.git#staging, so at
least this patch (or something like it) should go into qemu RSN.

Anthony, do you plan to cherry pick this into the xen-specific qemu
branch used for osstest tests ?

Thanks,
Ian.
Anthony PERARD Oct. 10, 2017, 10:32 a.m. UTC | #2 
On Mon, Oct 09, 2017 at 05:28:08PM +0100, Ian Jackson wrote:
> Ian Jackson writes ("[PATCH 1/8] xen: link against xentoolcore"):
> > From: Anthony PERARD <anthony.perard@citrix.com>
> > 
> > Xen libraries 4.10 will include a new xentoolcore library, without
> > which xendevicemodel et al will not work.
> 
> The xentoolcore library was just committed to xen.git#staging, so at
> least this patch (or something like it) should go into qemu RSN.

I don't think it is necessary to do anything in qemu. The linker should
find on its own the new libxentoolcore as long as an option
-Wl,-rpath-link= provide the right path to xentoolcore when building
qemu from xen.git.  In other cases, the pkg-config files should be
enough (configure doesn't need to known about a new xentoolcore.pc
file).

> Anthony, do you plan to cherry pick this into the xen-specific qemu
> branch used for osstest tests ?
> 
> Thanks,
> Ian.
Ian Jackson Oct. 10, 2017, 5:13 p.m. UTC | #3 
Anthony PERARD writes ("Re: [PATCH 1/8] xen: link against xentoolcore"):
> On Mon, Oct 09, 2017 at 05:28:08PM +0100, Ian Jackson wrote:
> > The xentoolcore library was just committed to xen.git#staging, so at
> > least this patch (or something like it) should go into qemu RSN.
> 
> I don't think it is necessary to do anything in qemu. The linker should
> find on its own the new libxentoolcore as long as an option
> -Wl,-rpath-link= provide the right path to xentoolcore when building
> qemu from xen.git.

But, the -rpath-link= specification in libxendevicemodel refers not to
the xen.git build tree, but to the eventual installed copy.

In my tests, this does in fact break the build.

>  In other cases, the pkg-config files should be
> enough (configure doesn't need to known about a new xentoolcore.pc
> file).

In that case, yes, the .pc works.

Ian.
Ian Jackson Oct. 19, 2017, 4:38 p.m. UTC | #4 
Anthony PERARD writes ("Re: [PATCH 1/8] xen: link against xentoolcore"):
> I don't think it is necessary to do anything in qemu. The linker should
> find on its own the new libxentoolcore as long as an option
> -Wl,-rpath-link= provide the right path to xentoolcore when building
> qemu from xen.git.  In other cases, the pkg-config files should be
> enough (configure doesn't need to known about a new xentoolcore.pc
> file).

It seems that the build still works, without this patch but without
the rest of my series too, because we end up passing
  -L/u/iwj/work/xen.git/tools/../tools/libs/toolcore
  -Wl,-rpath-link=/u/iwj/work/xen.git/tools/../tools/libs/toolcore
(or similar) on the qemu link line.  So when ld links against
libxenstore (say) it finds that xenstore needs toolcore and finds
toolcore in the relevant paths.

We still need this patch for the rest of the series, though.

Ian.
Anthony PERARD Oct. 19, 2017, 4:47 p.m. UTC | #5 
On Thu, Oct 19, 2017 at 05:38:10PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("Re: [PATCH 1/8] xen: link against xentoolcore"):
> > I don't think it is necessary to do anything in qemu. The linker should
> > find on its own the new libxentoolcore as long as an option
> > -Wl,-rpath-link= provide the right path to xentoolcore when building
> > qemu from xen.git.  In other cases, the pkg-config files should be
> > enough (configure doesn't need to known about a new xentoolcore.pc
> > file).
> 
> It seems that the build still works, without this patch but without
> the rest of my series too, because we end up passing
>   -L/u/iwj/work/xen.git/tools/../tools/libs/toolcore
>   -Wl,-rpath-link=/u/iwj/work/xen.git/tools/../tools/libs/toolcore
> (or similar) on the qemu link line.  So when ld links against
> libxenstore (say) it finds that xenstore needs toolcore and finds
> toolcore in the relevant paths.
> 
> We still need this patch for the rest of the series, though.

Of course, I was only arguing that this patch on its own is not usefull.

Do you need a signed-off-by or review-by from me? Since it looks like
I'm the author.
Ian Jackson Oct. 20, 2017, 10:25 a.m. UTC | #6 
Anthony PERARD writes ("Re: [PATCH 1/8] xen: link against xentoolcore"):
> On Thu, Oct 19, 2017 at 05:38:10PM +0100, Ian Jackson wrote:
> > We still need this patch for the rest of the series, though.
> 
> Of course, I was only arguing that this patch on its own is not usefull.

Right.  I wanted to accurately reflect the situation in the commit
message, hence the explanation.

> Do you need a signed-off-by or review-by from me? Since it looks like
> I'm the author.

Indeed, so I don't think it makes sense for you to say you've reviewed
it.

Ian.
diff mbox

Patch

diff --git a/configure b/configure
index fd7e3a5..6f691df 100755
--- a/configure
+++ b/configure
@@ -2072,7 +2072,7 @@  if test "$xen" != "no" ; then
       $($pkg_config --modversion xencontrol | sed 's/\./ /g') )"
     xen=yes
     xen_pc="xencontrol xenstore xenguest xenforeignmemory xengnttab"
-    xen_pc="$xen_pc xenevtchn xendevicemodel"
+    xen_pc="$xen_pc xenevtchn xendevicemodel xentoolcore"
     QEMU_CFLAGS="$QEMU_CFLAGS $($pkg_config --cflags $xen_pc)"
     libs_softmmu="$($pkg_config --libs $xen_pc) $libs_softmmu"
     LDFLAGS="$($pkg_config --libs $xen_pc) $LDFLAGS"
@@ -2104,18 +2104,20 @@  EOF
         cat > $TMPC <<EOF &&
 #undef XC_WANT_COMPAT_MAP_FOREIGN_API
 #include <xenforeignmemory.h>
+#include <xentoolcore.h>
 int main(void) {
   xenforeignmemory_handle *xfmem;
 
   xfmem = xenforeignmemory_open(0, 0);
   xenforeignmemory_map2(xfmem, 0, 0, 0, 0, 0, 0, 0);
+  xentoolcore_restrict_all(0);
 
   return 0;
 }
 EOF
-        compile_prog "" "$xen_libs -lxendevicemodel $xen_stable_libs"
+        compile_prog "" "$xen_libs -lxendevicemodel $xen_stable_libs -lxentoolcore"
       then
-      xen_stable_libs="-lxendevicemodel $xen_stable_libs"
+      xen_stable_libs="-lxendevicemodel $xen_stable_libs -lxentoolcore"
       xen_ctrl_version=41000
       xen=yes
     elif