On 9/22/20 12:44 PM, James Bottomley wrote: > On Tue, 2020-09-22 at 12:38 -0700, Randy Dunlap wrote: >> On 9/22/20 12:19 PM, James Bottomley wrote: >>> On Tue, 2020-09-22 at 11:54 -0700, Randy Dunlap wrote: >>>> On 9/22/20 8:53 AM, James Bottomley wrote: >>>>> I recently ran into this as an error from 0day. On x86 it's >>>>> pretty >>>>> much impossible to build a configuration where CONFIG_ASN1 >>>>> isn't >>>>> set, so you rarely notice a problem using the ASN.1 compiler >>>>> because something else has selected it. However, this compiler >>>>> is >>>>> never built if CONFIG_ASN1 isn't set and the error you get from >>>>> kbuild is particularly unhelpful: >>>>> >>>>> make[4]: *** No rule to make target 'security/keys/trusted- >>>>> keys/tpm2key.asn1.o', needed by 'security/keys/trusted- >>>>> keys/built- >>>>> in.a'. >>>>> make[4]: *** [scripts/Makefile.build:283: >>>>> security/keys/trusted- >>>>> keys/trusted_tpm2.o] Error 1 >>>>> make[4]: Target '__build' not remade because of errors. >>>>> >>>>> This patch changes the above error to the much easier to >>>>> diagnose: >>>>> >>>>> scripts/Makefile.build:387: *** CONFIG_ASN1 must be defined >>>>> for >>>>> the asn1_compiler. Stop. >>>>> make[3]: *** [scripts/Makefile.build:505: >>>>> security/keys/trusted- >>>>> keys] Error 2 >>>>> >>>>> James >>>>> >>>>> --- >>>>> >>>>> James Bottomley (1): >>>>> Makefile.build: Add an explicit error for missing ASN.1 >>>>> compiler >>>>> >>>>> scripts/Makefile.build | 5 +++++ >>>>> 1 file changed, 5 insertions(+) >>>> >>>> Is there a missing >>>> select ASN1 >>>> somewhere? >>> >>> You mean in the build used to produce the errors above? Yes, so >>> the >>> patch is to make the problem more explicit. >> >> I appreciate that the message can be improved, but it seems possible >> that some Kconfig could also be improved. > > I don't really see how. To find the problem you have to identify a > conditional build in the Makefile that requires the asn1 compiler but > for which the config option doesn't have a select ASN1. We don't > currently preserve the "what selected this symbol" information in > kconfig, which is what we'd need. Well, if you have a failing .config file, I would be glad to take a look at it... -- ~Randy
