Re: [Xen-devel] [PATCH] pass $($*.o-cflags) first to gcc/g++

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 9 Jul 2014, Paolo Bonzini wrote:
> Il 09/07/2014 22:34, Stefano Stabellini ha scritto:
> > rules.mak adds cflags specific to the target source file ($($@-cflags))
> > for last on the compiler command line.
> > 
> > As a consequence when compiling arm-a64.o, g++ might end up picking the
> > wrong utils.h header file, because it looks for utils.h on all the other
> > include paths first.
> > 
> > Fix the issue by passing the source file specific cflags first.
> > Do it consisently for *.c, *.cc, etc.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> 
> You can just as well have a bug that requires you to put the option last (for
> example adding -Wno-something or -O0), which is why
> $($@-cflags)/$($*.o-cflags) comes last.

I see. I can understand the reasoning, especially given the way
$@-cflags is used in block/Makefile.objs.  But in that case I would
think that there must be a better way to add -I$(libvixldir) from
disas/Makefile.objs. Maybe adding it to QEMU_CFLAGS is not so bad?

$(obj)/arm-a64.o: QEMU_CFLAGS := -I$(libvixldir) $(QEMU_CFLAGS)


> What package is it that has the conflicting utils.h file?  Any chance to get
> it fixed in your distro?  Here I get:
> 
> $ find /usr/include/ -name utils.h
> /usr/include/libnl3/netlink/utils.h
> /usr/include/libnl3/netlink/cli/utils.h
> /usr/include/id3/utils.h
> /usr/include/octave-3.6.4/octave/utils.h
> 
> but none of them have the path in -I.

It's Xen: when building QEMU as part of the Xen build process,
tools/Makefile uses --extra-cflags to add the local Xen directories to
the QEMU include path. However one of the Xen header files is named
utils.h, conflicting with utils.h from disas/libvixl.
It seems to be that --extra-cflags should come after the QEMU include
paths.

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