>>>> From: Fei Yang <fei.yang@xxxxxxxxx> >>>> Date: Mon, 26 Aug 2013 11:21:48 -0700 >>>> Subject: [PATCH] FIXDEP: error opening depfile >>>> >>>> Met a kernel build issue where fixdep fails to open a depfile, >>>> fixdep: error opening depfile: drivers/driver-name/.driver-code.o.d: >>>> No such file or directory >>>> make[4]: *** [drivers/driver-name/driver-code.o] Error 2 >>>> make[3]: *** [drivers/driver-name] Error 2 Don't know why the >>>> expected file was not created, but the assumption that the file had >>>> been created might not be true, so simply return for such failure. >>> >>> I tried to grep: >>> git grep "driver-name" >>> >>> No hits. >>> >>> Are you trying to fix a build issue with something out-of-tree - or is this only in linux-next? >>> >> Oh, I changed the driver and file name in the error message to avoid >> unnecessary confusion >You achieved quite the opposite :-). Yes, that appears to be a bad idea. >> as the driver is not an upstream one. But this issue happens randomly, >> not 100% reproducible. And it happens on different driver sometimes. >Are you able to reproduce this with the vanilla kernel? If so, details please. I have not tried vanilla kernel. >If not, then this can be something with your module's build system. Are you using anything fancier than > >$ cat Makefile >obj-m += my-module.o >$ make -C <kernel build tree> M=$PWD > Michal Nothing fancy except the kernel build is triggered by Android build system. And the driver is being built into the kernel with obj-(CONFIG_MY_DRIVER) += my-driver.o, so it's not even a loadable module. I thought fixdep is about finding module dependency, and it isn't needed for built-in drivers. Please correct me if I'm wrong. I want to understand if the .d file had never been generated or had been generated but deleted by the time fixdep tries to open it. Fei -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
