On 12.01.2023 08:46, Jan Beulich wrote: > On 11.01.2023 23:29, Andrew Cooper wrote: >> For posterity, >> https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/3585379553 is >> the issue in question. >> >> In file included from arch/x86/hvm/hvm.c:82: >> ./include/compat/hvm/hvm_op.h:6:10: fatal error: ../trace.h: No such >> file or directory >> 6 | #include "../trace.h" >> | ^~~~~~~~~~~~ >> compilation terminated. >> make[4]: *** [Rules.mk:246: arch/x86/hvm/hvm.o] Error 1 >> make[3]: *** [Rules.mk:320: arch/x86/hvm] Error 2 >> make[3]: *** Waiting for unfinished jobs.... >> >> >> All public headers use "../" relative includes for traversing the >> public/ hierarchy. This cannot feasibly change given our "copy this >> into your project" stance, but it means the compat headers have the same >> structure under compat/. >> >> This include is supposed to be including compat/trace.h but it was >> actually picking up x86's asm/trace.h, hence the build failure now that >> I've deleted the file. >> >> This demonstrates that trying to be clever with -iquote is a mistake. >> Nothing good can possibly come of having the <> and "" include paths >> being different. Therefore we must revert all uses of -iquote. > > I'm afraid I can't see the connection between use of -iquote and the bug > here.
In fact I think the issue was caused by CFLAGS += -I$(srctree)/arch/x86/include/asm/mach-generic CFLAGS += -I$(srctree)/arch/x86/include/asm/mach-default which allowed the compiler when seeing "../trace.h" to pick up arch/x86/include/asm/trace.h. No -iquote in sight here; all that happens is that #include "..." fall back to using -I specified paths when the file could not be found by using ""-only paths. Jan
