>From 5e6501efa26bc19dad0b43e3a2b0daa81408a8ae Mon Sep 17 00:00:00 2001
From: Fei Yang <[email protected]>
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.
Change-Id: I299c01f2e3f6e1d04b19ced34ebeb964e16494e6
Signed-off-by: Fei Yang <[email protected]>
---
scripts/basic/fixdep.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index cb1f50c..2c065e5 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -377,7 +377,7 @@ static void print_deps(void)
if (fd < 0) {
fprintf(stderr, "fixdep: error opening depfile: ");
perror(depfile);
- exit(2);
+ return;
}
if (fstat(fd, &st) < 0) {
fprintf(stderr, "fixdep: error fstat'ing depfile: ");
--
1.7.9.5
On Mon, Aug 26, 2013 at 07:22:46PM +0000, Yang, Fei wrote:
> >From 5e6501efa26bc19dad0b43e3a2b0daa81408a8ae Mon Sep 17 00:00:00 2001
> From: Fei Yang <[email protected]>
> 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?
Sam
>> From: Fei Yang <[email protected]>
>> 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 as the driver is not an upstream one. But this issue happens randomly, not 100% reproducible. And it happens on different driver sometimes. So I don't think it would be driver related and pointing out the driver name would not help much anyway.
What I'm trying to understand is under what condition fixdep is triggered in the kernel build process. Is the .d file always generated for every driver? If that file is always created, could it be a timing issue that the .d file was actually created but then deleted when fixdep trying to find it?
Thank you Sam! I'm not familiar with kernel build scripts, any idea is really appreciated.
-Fei
On 27.8.2013 21:05, Yang, Fei wrote:
>>> From: Fei Yang <[email protected]>
>>> 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 :-).
> 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. 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
On 28.8.2013 17:07, Michal Marek wrote:
> Are you able to reproduce this with the vanilla kernel? If so, details
> please. 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
make -C <kernel build tree> M=$PWD modules
Michal
>>>> From: Fei Yang <[email protected]>
>>>> 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
Dne 28.8.2013 18:27, Yang, Fei napsal(a):
> I thought fixdep is about finding module dependency, and it isn't
> needed for built-in drivers. Please correct me if I'm wrong.
fixdep filters the *.d files generated by gcc. These files record source
-> object file dependencies, to not miss rebuilds.
Michal
>> I thought fixdep is about finding module dependency, and it isn't
>> needed for built-in drivers. Please correct me if I'm wrong.
>
>fixdep filters the *.d files generated by gcc. These files record source
>-> object file dependencies, to not miss rebuilds.
OK, then it's more likely to be a timing issue. I'm running my builds on a machine with 32 cores, and as the build is distributed to multi-processors, there might be a synchronization issue.
Do you know how the .d files getting deleted normally? I see only .o.cmd file left after the build is completed.
Michal
>
> I thought fixdep is about finding module dependency, and
> it isn't needed for built-in drivers.
> Please correct me if I'm wrong.
You are wrong...
Fixdep conatins all the dependencies used to determine if we shall rebuild foo.o.
It has nothing to do with modules or not.
Following happens when you build foo.o from foo.c:
1) gcc -Wp,-MD,foo.o.d foo.c -o foo.o
This produces two files:
foo.o.d - contains all files included by foo.c, recursive (try it out!)
foo.o - the object file
2) fixdep foo.o.d foo.o gcc -Wp,-MD,foo.o.d foo.c -o foo.o > foo.o.tmp
fixdep now does the following:
- Assign the comandline to a variable
- List all dependencies (files included)
- Scan the dependen file for CONFIG_* symbols
- for each CONFIG_* symbol add a $(wildcard ...) reference to a symbol in
include/generated/config/... that represents the CONFIG_ symbol
Everything is stored in foo.o.tmp
3) delete foo.o.cmd
4) rename foo.o.tmp to foo.o.cmd
Magic happens in Kbuild.include, Makefile.lib and Makefile.build.
But it make take some cup of coffee to grasp it.
For find and fix whatever race condition you hit.
Sam
>
> 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.
>
Please teach yourself to punch new-line now and then.
Sam
On 29.8.2013 19:55, Sam Ravnborg wrote:
> Magic happens in Kbuild.include, Makefile.lib and Makefile.build.
> But it make take some cup of coffee to grasp it.
>
> For find and fix whatever race condition you hit.
BTW, there is a fix in 3.11 that might be relevant for you:
commit 4d47dde47f7dd95042fa56283d948f50dd4b509c
Author: 张忠山 <[email protected]>
Date: Sun Jun 30 17:09:28 2013 +0800
kbuild: create directory for dir/file.o
At least, it's worth trying.
Michal