[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <02E7334B1630744CBDC55DA85862258348E4792D@ORSMSX102.amr.corp.intel.com>
Date: Wed, 28 Aug 2013 16:27:46 +0000
From: "Yang, Fei" <fei.yang@...el.com>
To: Michal Marek <mmarek@...e.cz>
CC: Sam Ravnborg <sam@...nborg.org>,
"linux-kbuild@...r.kernel.org" <linux-kbuild@...r.kernel.org>,
"'linux-kernel@...r.kernel.org' (linux-kernel@...r.kernel.org)"
<linux-kernel@...r.kernel.org>
Subject: RE: Can anyone suggest a better fix? Not sure if I understand the
problem, but the patch fixed it
>>>> From: Fei Yang <fei.yang@...el.com>
>>>> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists