On Tue, Aug 16, 2022 at 03:02:10PM +0200, Jan Beulich wrote: > On 16.08.2022 12:30, Anthony PERARD wrote: > > We can't have a source file with the same name that exist in both the > > common code and in the arch specific code for efi/. This can lead to > > comfusion in make and it can pick up the wrong source file. This issue > > lead to a failure to build a pv-shim for x86 out-of-tree, as this is > > one example of an x86 build using the efi/stub.c. > > > > The issue is that in out-of-tree, make might find x86/efi/stub.c via > > VPATH, but as the target needs to be rebuilt due to FORCE, make > > actually avoid changing the source tree and rebuilt the target with > > VPATH ignored, so $@ lead to the build tree where "stub.c" dosen't > > exist yet so a link is made to "common/stub.c". > > > > Rework the new common/stub.c file to have a different name than the > > already existing one. And build both *stub.c as two different objects. > > This mean we have to move some efi_compat_* aliases which are probably > > useless for Arm. > > These useless aliases want avoiding there imo. Already when the original > series was discussed, I requested to avoid introduction of a file named > common-stub.c or alike.
Yeah, I've notice that. This is why the build is broken under specific condition. > If names need to be different, can't we follow > boot.c's model and introduce a per-arch efi/stub.h which stub.c would > include at a suitable position (and which right now would be empty for > Arm)? That seems to be possible. But how is it better than having two different source file? The only thing is to avoid exporting the efi_compat_* symbol aliases. The downside is we would have another weird looking not really header which is actually just part of a source file. At least, "stub.c" and "stub.h" would be two different names, we just change the extension rather than the basename. Cheers, -- Anthony PERARD
