qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] prepend the include path of libvixl header file


From: Stefano Stabellini
Subject: Re: [Qemu-devel] [PATCH] prepend the include path of libvixl header files
Date: Tue, 8 Jul 2014 12:55:58 +0100
User-agent: Alpine 2.02 (DEB 1266 2009-07-14)

On Tue, 8 Jul 2014, Peter Maydell wrote:
> On 7 July 2014 16:25, Stefano Stabellini
> <address@hidden> wrote:
> > Currently the Makefile of disas/libvixl appends
> > -I$(SRC_PATH)/disas/libvixl to QEMU_CFLAGS. As a consequence C++ files
> > that #include "utils.h", such as disas/libvixl/a64/instructions-a64.cc,
> > are going to look for utils.h on all the other include paths first.
> >
> > When building QEMU as part of the Xen make system, another unrelated
> > utils.h file is going to be chosen for inclusion, causing a build
> > failure:
> >
> > In file included from disas/libvixl/a64/instructions-a64.cc:27:0:
> > /qemu/disas/libvixl/a64/instructions-a64.h:88:64: error:
> > ‘rawbits_to_float’ was not declared in this scope
> >  const float kFP32PositiveInfinity = rawbits_to_float(0x7f800000);
> >
> > Fix the problem by prepending (rather than appending) the libvixl
> > include path to QEMU_CFLAGS.
> >
> > Signed-off-by: Stefano Stabellini <address@hidden>
> >
> > ---
> >
> > diff --git a/disas/libvixl/Makefile.objs b/disas/libvixl/Makefile.objs
> > index 0adb3ce..17e6565 100644
> > --- a/disas/libvixl/Makefile.objs
> > +++ b/disas/libvixl/Makefile.objs
> > @@ -3,6 +3,6 @@ libvixl_OBJS = utils.o \
> >                 a64/decoder-a64.o \
> >                 a64/disasm-a64.o
> >
> > -$(addprefix $(obj)/,$(libvixl_OBJS)): QEMU_CFLAGS += 
> > -I$(SRC_PATH)/disas/libvixl
> > +$(addprefix $(obj)/,$(libvixl_OBJS)): QEMU_CFLAGS := 
> > -I$(SRC_PATH)/disas/libvixl $(QEMU_CFLAGS)
> >
> >  common-obj-$(CONFIG_ARM_A64_DIS) += $(libvixl_OBJS)
> 
> Reviewed-by: Peter Maydell <address@hidden>
> 
> I spent a few moments wondering if the conversion of
> QEMU_CFLAGS from recursively-expanded to simply-expanded
> would be a problem, but because this is a target-specific
> variable it's pretty much going to be expanded at the same
> point that it would be anyhow.
 
Thanks Peter.
Are you going to pick it up or do you want me to send a pull request?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]