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 <[email protected]>
---
arch/arm64/crypto/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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)
--
2.0.1
--
Andreas Schwab, SUSE Labs, [email protected]
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
On 30 June 2014 15:14, Andreas Schwab <[email protected]> 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.
> Signed-off-by: Andreas Schwab <[email protected]>
> ---
> arch/arm64/crypto/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> 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)
> --
> 2.0.1
>
> --
> Andreas Schwab, SUSE Labs, [email protected]
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Ard Biesheuvel <[email protected]> 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.
--
Andreas Schwab, SUSE Labs, [email protected]
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
On 30 June 2014 15:56, Andreas Schwab <[email protected]> wrote:
> Ard Biesheuvel <[email protected]> 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.
Ard Biesheuvel <[email protected]> writes:
> On 30 June 2014 15:56, Andreas Schwab <[email protected]> wrote:
>> Ard Biesheuvel <[email protected]> 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.
--
Andreas Schwab, SUSE Labs, [email protected]
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
On 24 July 2014 14:29, Andreas Schwab <[email protected]> wrote:
> Ard Biesheuvel <[email protected]> writes:
>
>> On 30 June 2014 15:56, Andreas Schwab <[email protected]> wrote:
>>> Ard Biesheuvel <[email protected]> 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 <[email protected]> wrote:
> On 24 July 2014 14:29, Andreas Schwab <[email protected]> wrote:
>> Ard Biesheuvel <[email protected]> writes:
>>
>>> On 30 June 2014 15:56, Andreas Schwab <[email protected]> wrote:
>>>> Ard Biesheuvel <[email protected]> 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?
--
Ard.
You are not using CONFIG_MODVERSIONS.
Andreas.
--
Andreas Schwab, SUSE Labs, [email protected]
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
On 24 July 2014 15:26, Andreas Schwab <[email protected]> wrote:
> You are not using CONFIG_MODVERSIONS.
>
I am
Ard Biesheuvel <[email protected]> writes:
> On 24 July 2014 15:26, Andreas Schwab <[email protected]> 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.
--
Andreas Schwab, SUSE Labs, [email protected]
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
On 24 July 2014 15:40, Andreas Schwab <[email protected]> wrote:
> Ard Biesheuvel <[email protected]> writes:
>
>> On 24 July 2014 15:26, Andreas Schwab <[email protected]> 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 <[email protected]> wrote:
> On 24 July 2014 15:40, Andreas Schwab <[email protected]> wrote:
>> Ard Biesheuvel <[email protected]> writes:
>>
>>> On 24 July 2014 15:26, Andreas Schwab <[email protected]> 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 <[email protected]>
Thanks for your patience.
--
Ard.
On Thu, Jul 24, 2014 at 04:24:48PM +0200, Ard Biesheuvel wrote:
> On 24 July 2014 16:18, Ard Biesheuvel <[email protected]> wrote:
> > On 24 July 2014 15:40, Andreas Schwab <[email protected]> wrote:
> >> Ard Biesheuvel <[email protected]> writes:
> >>
> >>> On 24 July 2014 15:26, Andreas Schwab <[email protected]> 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 <[email protected]>
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 <[email protected]> wrote:
> On Thu, Jul 24, 2014 at 04:24:48PM +0200, Ard Biesheuvel wrote:
>> On 24 July 2014 16:18, Ard Biesheuvel <[email protected]> wrote:
>> > On 24 July 2014 15:40, Andreas Schwab <[email protected]> wrote:
>> >> Ard Biesheuvel <[email protected]> writes:
>> >>
>> >>> On 24 July 2014 15:26, Andreas Schwab <[email protected]> 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 <[email protected]>
>
> 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 <[email protected]> wrote:
> > On Thu, Jul 24, 2014 at 04:24:48PM +0200, Ard Biesheuvel wrote:
> >> On 24 July 2014 16:18, Ard Biesheuvel <[email protected]> wrote:
> >> > On 24 July 2014 15:40, Andreas Schwab <[email protected]> wrote:
> >> >> Ard Biesheuvel <[email protected]> writes:
> >> >>
> >> >>> On 24 July 2014 15:26, Andreas Schwab <[email protected]> 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 <[email protected]>
> >
> > 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 <[email protected]> wrote:
> On Thu, Jul 24, 2014 at 09:25:13PM +0200, Ard Biesheuvel wrote:
>> On 24 July 2014 18:12, Sam Ravnborg <[email protected]> wrote:
>> > On Thu, Jul 24, 2014 at 04:24:48PM +0200, Ard Biesheuvel wrote:
>> >> On 24 July 2014 16:18, Ard Biesheuvel <[email protected]> wrote:
>> >> > On 24 July 2014 15:40, Andreas Schwab <[email protected]> wrote:
>> >> >> Ard Biesheuvel <[email protected]> writes:
>> >> >>
>> >> >>> On 24 July 2014 15:26, Andreas Schwab <[email protected]> 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 <[email protected]>
>> >
>> > 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 <[email protected]> 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?
--
Ard.
On Mon, Jul 28, 2014 at 07:00:17PM +0200, Ard Biesheuvel wrote:
> On 27 July 2014 20:40, Sam Ravnborg <[email protected]> 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