Re: [Xen-users] Build error: "unknown type name vmemrange_t"

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Mon, 2015-02-09 at 13:14 -0700, E. Westbrook wrote:
> Thanks for the reply.
> 
> On 02/09/2015 06:35 AM, Ian Campbell wrote:
> > I can't seem to find a2b4af1 in xen.git. Are you sure it is correct? Can
> > you provide precise git urls and branch names please.
> 
> Weird, I have no idea what I was looking at when I wrote that.  But
> here's what I'm looking at right now where I'm reproducing the
> problem:
> 
> * d8e78d6 - (upstream/staging-4.5, upstream/stable-4.5) bunzip2: off
> by one in get_next_block() (6 days ago) <Dan Carpenter>
> 
> where "upstream" is "git://xenbits.xen.org/xen.git".  My separate qemu
> build is from upstream as you confirm.  (I don't know if I still need
> to have it separate, if it's disadvantageous to do so -- more below.)
> 
> > The qemu version you give is for upstream qemu, but:
> >> ./xen/tools/qemu-xen-traditional-dir/rules.mak:3: recipe for target 
> >> 'qemu-nbd.o' failed
> > 
> > Suggests the error is from the qemu-trad branch. Are you allowing the
> > Xen build system to pick and clone the qemu trees or are you doing
> > something by hand?
> 
> I'm trying to let Xen do as it likes.  The only two things I'm doing
> in a fresh xen.git clone are "./configure --prefix=usr" and then "make
> world".  I'd happily stop maintaining a separate qemu if I can, and if
> there's advantage in that.  Very appreciative to know what you think.

I'm confused -- you say you are letting Xen do as it likes, but you also
imply that you are maintaining a separate qemu, which is inconsistent.

If you just let Xen do it's thing then no separate qemu would be
required.

Ian.


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users