| Message ID | mvmvbri4k06.fsf@hawking.suse.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 30 June 2014 15:14, Andreas Schwab <schwab@suse.de> wrote: > This fixes the following build failure: > > CC [M] arch/arm64/crypto/aes-glue-ce.o > ld: cannot find arch/arm64/crypto/aes-glue-ce.o: No such file or directory > scripts/Makefile.build:393: recipe for target 'arch/arm64/crypto/aes-ce-blk.o' failed > make[1]: *** [arch/arm64/crypto/aes-ce-blk.o] Error 1 > Makefile:893: recipe for target 'arch/arm64/crypto' failed > make: *** [arch/arm64/crypto] Error 2 > > The $(obj)/aes-glue-%.o rule only creates $(obj)/.tmp_aes-glue-ce.o, it > should use if_changed_rule instead of if_changed_dep. > Oops, my bad Out of curiosity, how did you trigger this failure? I have build this code numerous times (and so have others) and I have never seen this failure.
Ard Biesheuvel <ard.biesheuvel@linaro.org> writes: > Out of curiosity, how did you trigger this failure? I have build this > code numerous times (and so have others) and I have never seen this > failure. Did you ever start with a clean tree? Andreas.
On 30 June 2014 15:56, Andreas Schwab <schwab@suse.de> wrote: > Ard Biesheuvel <ard.biesheuvel@linaro.org> writes: > >> Out of curiosity, how did you trigger this failure? I have build this >> code numerous times (and so have others) and I have never seen this >> failure. > > Did you ever start with a clean tree? > Yep, building both in-tree and out-of-tree, no trouble at all.
Ard Biesheuvel <ard.biesheuvel@linaro.org> writes: > On 30 June 2014 15:56, Andreas Schwab <schwab@suse.de> wrote: >> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes: >> >>> Out of curiosity, how did you trigger this failure? I have build this >>> code numerous times (and so have others) and I have never seen this >>> failure. >> >> Did you ever start with a clean tree? >> > > Yep, building both in-tree and out-of-tree, no trouble at all. So you probably didn't configure them as modules. Andreas.
On 24 July 2014 14:29, Andreas Schwab <schwab@suse.de> wrote: > Ard Biesheuvel <ard.biesheuvel@linaro.org> writes: > >> On 30 June 2014 15:56, Andreas Schwab <schwab@suse.de> wrote: >>> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes: >>> >>>> Out of curiosity, how did you trigger this failure? I have build this >>>> code numerous times (and so have others) and I have never seen this >>>> failure. >>> >>> Did you ever start with a clean tree? >>> >> >> Yep, building both in-tree and out-of-tree, no trouble at all. > > So you probably didn't configure them as modules. > Yes, all the time, in fact. They have now been added as built-ins to the defconfig, but I always build as modules, because it is far easier when developing.
On 24 July 2014 14:35, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > On 24 July 2014 14:29, Andreas Schwab <schwab@suse.de> wrote: >> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes: >> >>> On 30 June 2014 15:56, Andreas Schwab <schwab@suse.de> wrote: >>>> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes: >>>> >>>>> Out of curiosity, how did you trigger this failure? I have build this >>>>> code numerous times (and so have others) and I have never seen this >>>>> failure. >>>> >>>> Did you ever start with a clean tree? >>>> >>> >>> Yep, building both in-tree and out-of-tree, no trouble at all. >> >> So you probably didn't configure them as modules. >> > > Yes, all the time, in fact. They have now been added as built-ins to > the defconfig, but I always build as modules, because it is far easier > when developing. Also, looking into this a bit more, in my case I do see arch/arm64/crypto/.aes-glue-ce.o.cmd containing the command line and the full set of include/config/... rules that are used to track dependencies on the configuration. So what strikes me as odd is this: > CC [M] arch/arm64/crypto/aes-glue-ce.o > ld: cannot find arch/arm64/crypto/aes-glue-ce.o: No such file or directory so it seems make is perfectly happy to create the aes-glue-ce.o file, but the subsequent ld that uses it as input cannot find it. Perhaps the dependencies are screwed up elsewehere? Are there any other circumstances of interest? How many threads are you building in parallel? Other steps to reproduce?
You are not using CONFIG_MODVERSIONS. Andreas.
On 24 July 2014 15:26, Andreas Schwab <schwab@suse.de> wrote: > You are not using CONFIG_MODVERSIONS. > I am
Ard Biesheuvel <ard.biesheuvel@linaro.org> writes: > On 24 July 2014 15:26, Andreas Schwab <schwab@suse.de> wrote: >> You are not using CONFIG_MODVERSIONS. >> > > I am No, you aren't, since you say that your .cmd contains a command to create aes-glue-ce.o, which with CONFIG_MODVERSIONS it doesn't. Andreas.
On 24 July 2014 15:40, Andreas Schwab <schwab@suse.de> wrote: > Ard Biesheuvel <ard.biesheuvel@linaro.org> writes: > >> On 24 July 2014 15:26, Andreas Schwab <schwab@suse.de> wrote: >>> You are not using CONFIG_MODVERSIONS. >>> >> >> I am > > No, you aren't, since you say that your .cmd contains a command to > create aes-glue-ce.o, which with CONFIG_MODVERSIONS it doesn't. > OK, you're right, it contains a command to create .tmp_aes-glue-ce.o. But I am still not seeing the error you are seeing, strangely enough.
On 24 July 2014 16:18, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > On 24 July 2014 15:40, Andreas Schwab <schwab@suse.de> wrote: >> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes: >> >>> On 24 July 2014 15:26, Andreas Schwab <schwab@suse.de> wrote: >>>> You are not using CONFIG_MODVERSIONS. >>>> >>> >>> I am >> >> No, you aren't, since you say that your .cmd contains a command to >> create aes-glue-ce.o, which with CONFIG_MODVERSIONS it doesn't. >> > > OK, you're right, it contains a command to create .tmp_aes-glue-ce.o. > But I am still not seeing the error you are seeing, strangely enough. OK, now I am seeing it. Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Thanks for your patience.
On Thu, Jul 24, 2014 at 04:24:48PM +0200, Ard Biesheuvel wrote: > On 24 July 2014 16:18, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > > On 24 July 2014 15:40, Andreas Schwab <schwab@suse.de> wrote: > >> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes: > >> > >>> On 24 July 2014 15:26, Andreas Schwab <schwab@suse.de> wrote: > >>>> You are not using CONFIG_MODVERSIONS. > >>>> > >>> > >>> I am > >> > >> No, you aren't, since you say that your .cmd contains a command to > >> create aes-glue-ce.o, which with CONFIG_MODVERSIONS it doesn't. > >> > > > > OK, you're right, it contains a command to create .tmp_aes-glue-ce.o. > > But I am still not seeing the error you are seeing, strangely enough. > > OK, now I am seeing it. > > Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Jumping in the end of the thread here - sorry for that. Another way to solve this would be to create two small wrapper files: aes-glue-neon.c - which include aes-glue.c aes-glue-ce.c that include aes-glue.c Then you could use standard kbuild support for building your module. And we will not potentially break it when we change cc_o_c in the near future. Sam
On 24 July 2014 18:12, Sam Ravnborg <sam@ravnborg.org> wrote: > On Thu, Jul 24, 2014 at 04:24:48PM +0200, Ard Biesheuvel wrote: >> On 24 July 2014 16:18, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: >> > On 24 July 2014 15:40, Andreas Schwab <schwab@suse.de> wrote: >> >> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes: >> >> >> >>> On 24 July 2014 15:26, Andreas Schwab <schwab@suse.de> wrote: >> >>>> You are not using CONFIG_MODVERSIONS. >> >>>> >> >>> >> >>> I am >> >> >> >> No, you aren't, since you say that your .cmd contains a command to >> >> create aes-glue-ce.o, which with CONFIG_MODVERSIONS it doesn't. >> >> >> > >> > OK, you're right, it contains a command to create .tmp_aes-glue-ce.o. >> > But I am still not seeing the error you are seeing, strangely enough. >> >> OK, now I am seeing it. >> >> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> > > Jumping in the end of the thread here - sorry for that. > No worries > Another way to solve this would be to create two > small wrapper files: > aes-glue-neon.c - which include aes-glue.c > aes-glue-ce.c that include aes-glue.c > > Then you could use standard kbuild support for building your module. > And we will not potentially break it when we change cc_o_c in the near future. > I see how that would fix this issue, but frankly, if we need to add .c files that only #include other .c files to support building multiple objects from a single .c file, I think the flaw is in the build system, and I would rather fix the build system instead. Cheers, Ard.
On Thu, Jul 24, 2014 at 09:25:13PM +0200, Ard Biesheuvel wrote: > On 24 July 2014 18:12, Sam Ravnborg <sam@ravnborg.org> wrote: > > On Thu, Jul 24, 2014 at 04:24:48PM +0200, Ard Biesheuvel wrote: > >> On 24 July 2014 16:18, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > >> > On 24 July 2014 15:40, Andreas Schwab <schwab@suse.de> wrote: > >> >> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes: > >> >> > >> >>> On 24 July 2014 15:26, Andreas Schwab <schwab@suse.de> wrote: > >> >>>> You are not using CONFIG_MODVERSIONS. > >> >>>> > >> >>> > >> >>> I am > >> >> > >> >> No, you aren't, since you say that your .cmd contains a command to > >> >> create aes-glue-ce.o, which with CONFIG_MODVERSIONS it doesn't. > >> >> > >> > > >> > OK, you're right, it contains a command to create .tmp_aes-glue-ce.o. > >> > But I am still not seeing the error you are seeing, strangely enough. > >> > >> OK, now I am seeing it. > >> > >> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> > > > > Jumping in the end of the thread here - sorry for that. > > > > No worries > > > Another way to solve this would be to create two > > small wrapper files: > > aes-glue-neon.c - which include aes-glue.c > > aes-glue-ce.c that include aes-glue.c > > > > Then you could use standard kbuild support for building your module. > > And we will not potentially break it when we change cc_o_c in the near future. > > > > I see how that would fix this issue, but frankly, if we need to add .c > files that only #include other .c files to support building multiple > objects from a single .c file, I think the flaw is in the build > system, and I would rather fix the build system instead. The kbuild syntax could be extended to allow building multiple .o files from a single .c file. But the need for this feature is so seldom that people would not recognize the syntax most likely. Btw. the current solution is already faulty - even with the fix. There are no support for make C=2 arch/.../crypto/ Therefore - for now the correct fix is to use two wrapper .c files, and accept this. It will not have the C=2 problem above. Sam
On 24 July 2014 22:45, Sam Ravnborg <sam@ravnborg.org> wrote: > On Thu, Jul 24, 2014 at 09:25:13PM +0200, Ard Biesheuvel wrote: >> On 24 July 2014 18:12, Sam Ravnborg <sam@ravnborg.org> wrote: >> > On Thu, Jul 24, 2014 at 04:24:48PM +0200, Ard Biesheuvel wrote: >> >> On 24 July 2014 16:18, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: >> >> > On 24 July 2014 15:40, Andreas Schwab <schwab@suse.de> wrote: >> >> >> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes: >> >> >> >> >> >>> On 24 July 2014 15:26, Andreas Schwab <schwab@suse.de> wrote: >> >> >>>> You are not using CONFIG_MODVERSIONS. >> >> >>>> >> >> >>> >> >> >>> I am >> >> >> >> >> >> No, you aren't, since you say that your .cmd contains a command to >> >> >> create aes-glue-ce.o, which with CONFIG_MODVERSIONS it doesn't. >> >> >> >> >> > >> >> > OK, you're right, it contains a command to create .tmp_aes-glue-ce.o. >> >> > But I am still not seeing the error you are seeing, strangely enough. >> >> >> >> OK, now I am seeing it. >> >> >> >> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> >> > >> > Jumping in the end of the thread here - sorry for that. >> > >> >> No worries >> >> > Another way to solve this would be to create two >> > small wrapper files: >> > aes-glue-neon.c - which include aes-glue.c >> > aes-glue-ce.c that include aes-glue.c >> > >> > Then you could use standard kbuild support for building your module. >> > And we will not potentially break it when we change cc_o_c in the near future. >> > >> >> I see how that would fix this issue, but frankly, if we need to add .c >> files that only #include other .c files to support building multiple >> objects from a single .c file, I think the flaw is in the build >> system, and I would rather fix the build system instead. > The kbuild syntax could be extended to allow building multiple .o files from > a single .c file. But the need for this feature is so seldom that > people would not recognize the syntax most likely. > True > Btw. the current solution is already faulty - even with the fix. > There are no support for make C=2 arch/.../crypto/ > So can you elaborate on how it is faulty? > Therefore - for now the correct fix is to use two wrapper .c files, > and accept this. It will not have the C=2 problem above. > > Sam
> > > Btw. the current solution is already faulty - even with the fix. > > There are no support for make C=2 arch/.../crypto/ > > > > So can you elaborate on how it is faulty? When you run "make C=2 arch/.../crypto/" then sparse shall be run for all .c files also if they are already built. But due to the re-implementation of some parts of the kbuild logic in the makefile this does not happen with the -glue file. A minor detail - but this may not be the only wreckage we see over time. Sam
On 27 July 2014 20:40, Sam Ravnborg <sam@ravnborg.org> wrote: >> >> > Btw. the current solution is already faulty - even with the fix. >> > There are no support for make C=2 arch/.../crypto/ >> > >> >> So can you elaborate on how it is faulty? > > When you run "make C=2 arch/.../crypto/" then sparse shall be run > for all .c files also if they are already built. > But due to the re-implementation of some parts of the kbuild logic > in the makefile this does not happen with the -glue file. > > A minor detail - but this may not be the only wreckage we see over time. > I agree. Any suggestions for a generic way to solve this? Perhaps something like this in scripts/Makefile.build template_rule = $(obj)/$(tmpl)%.c: $(src)/$(tmpl).c ; @cp $$(^) $$(@) $(eval $(foreach tmpl,$(TEMPLATES),$(template_rule))) so that arch/arm64/crypto/Makefile only has to define TEMPLATES += aes-glue so that all dependencies on aes-glueXXX.c are satisfied by aes-glue.c? BTW, while looking into this issue, I noticed something else that is strange: after touch'ing sha1-ce-glue.c in arch/arm64/crypto and re-executing 'make V=2', this is what I get make[1]: Entering directory `/home/ard/linux-arm64-build' CHK include/config/kernel.release Using /home/ard/linux-2.6 as source for kernel GEN ./Makefile CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CALL /home/ard/linux-2.6/scripts/checksyscalls.sh - due to target missing CHK include/generated/compile.h CC arch/arm64/crypto/sha1-ce-glue.o - due to: /home/ard/linux-2.6/arch/arm64/crypto/sha1-ce-glue.c LD arch/arm64/crypto/sha1-ce.o - due to: arch/arm64/crypto/sha1-ce-glue.o LD arch/arm64/crypto/sha2-ce.o - due to: arch/arm64/crypto/sha1-ce-glue.o LD arch/arm64/crypto/ghash-ce.o - due to: arch/arm64/crypto/sha1-ce-glue.o LD arch/arm64/crypto/aes-ce-ccm.o - due to: arch/arm64/crypto/sha1-ce-glue.o LD arch/arm64/crypto/built-in.o - due to: arch/arm64/crypto/sha1-ce.o arch/arm64/crypto/sha2-ce.o arch/arm64/crypto/ghash-ce.o arch/arm64/crypto/aes-ce-ccm.o CHK kernel/config_data.h LINK vmlinux - due to: arch/arm64/crypto/built-in.o IOW, unrelated object files are detected as being out of date. (This is after running make mrproper, and with the aes-glue-% related rules and definitions commented out, just to make sure this is not related to the issue you have identified) Any ideas?
On Mon, Jul 28, 2014 at 07:00:17PM +0200, Ard Biesheuvel wrote: > On 27 July 2014 20:40, Sam Ravnborg <sam@ravnborg.org> wrote: > >> > >> > Btw. the current solution is already faulty - even with the fix. > >> > There are no support for make C=2 arch/.../crypto/ > >> > > >> > >> So can you elaborate on how it is faulty? > > > > When you run "make C=2 arch/.../crypto/" then sparse shall be run > > for all .c files also if they are already built. > > But due to the re-implementation of some parts of the kbuild logic > > in the makefile this does not happen with the -glue file. > > > > A minor detail - but this may not be the only wreckage we see over time. > > > > I agree. Any suggestions for a generic way to solve this? Yes - two small .c file that each include the same glue file. Anything else is over-engineering. > BTW, while looking into this issue, I noticed something else that is strange: > after touch'ing sha1-ce-glue.c in arch/arm64/crypto and re-executing > 'make V=2', this is what I get > > make[1]: Entering directory `/home/ard/linux-arm64-build' > CHK include/config/kernel.release > Using /home/ard/linux-2.6 as source for kernel > GEN ./Makefile > CHK include/generated/uapi/linux/version.h > CHK include/generated/utsrelease.h > CALL /home/ard/linux-2.6/scripts/checksyscalls.sh - due to target missing > CHK include/generated/compile.h > CC arch/arm64/crypto/sha1-ce-glue.o - due to: > /home/ard/linux-2.6/arch/arm64/crypto/sha1-ce-glue.c > LD arch/arm64/crypto/sha1-ce.o - due to: arch/arm64/crypto/sha1-ce-glue.o > LD arch/arm64/crypto/sha2-ce.o - due to: arch/arm64/crypto/sha1-ce-glue.o > LD arch/arm64/crypto/ghash-ce.o - due to: > arch/arm64/crypto/sha1-ce-glue.o > LD arch/arm64/crypto/aes-ce-ccm.o - due to: > arch/arm64/crypto/sha1-ce-glue.o > LD arch/arm64/crypto/built-in.o - due to: > arch/arm64/crypto/sha1-ce.o arch/arm64/crypto/sha2-ce.o > arch/arm64/crypto/ghash-ce.o arch/arm64/crypto/aes-ce-ccm.o > CHK kernel/config_data.h > LINK vmlinux - due to: arch/arm64/crypto/built-in.o Just from inspecting the above I have no idea. And I have no arm64 toolchain installed to test myself. So for now no clue - sorry. Sam
diff --git a/arch/arm64/crypto/Makefile b/arch/arm64/crypto/Makefile index 2070a56..a3f935f 100644 --- a/arch/arm64/crypto/Makefile +++ b/arch/arm64/crypto/Makefile @@ -35,4 +35,4 @@ AFLAGS_aes-neon.o := -DINTERLEAVE=4 CFLAGS_aes-glue-ce.o := -DUSE_V8_CRYPTO_EXTENSIONS $(obj)/aes-glue-%.o: $(src)/aes-glue.c FORCE - $(call if_changed_dep,cc_o_c) + $(call if_changed_rule,cc_o_c)
This fixes the following build failure: CC [M] arch/arm64/crypto/aes-glue-ce.o ld: cannot find arch/arm64/crypto/aes-glue-ce.o: No such file or directory scripts/Makefile.build:393: recipe for target 'arch/arm64/crypto/aes-ce-blk.o' failed make[1]: *** [arch/arm64/crypto/aes-ce-blk.o] Error 1 Makefile:893: recipe for target 'arch/arm64/crypto' failed make: *** [arch/arm64/crypto] Error 2 The $(obj)/aes-glue-%.o rule only creates $(obj)/.tmp_aes-glue-ce.o, it should use if_changed_rule instead of if_changed_dep. Signed-off-by: Andreas Schwab <schwab@suse.de> --- arch/arm64/crypto/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)