linux-next: build failure after merge of the tip tree

linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 608 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

x86_64-linux-gcc: arch/x86/lib/memmove_64.c: No such file or directory

Caused by commit 9599ec0471deae24044241e2173090d2cbc0e899 ("x86-64, mem:
Convert memmove() to assembly file and fix return value bug") interacting
with our build system.

After removing arch/x86/lib/.memmove_64.o.cmd (left over from the build
before merging the tip tree) from my object tree, it built correctly.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 966 bytes --]

Hi all,

On Mon, 31 Jan 2011 15:42:59 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> x86_64-linux-gcc: arch/x86/lib/memmove_64.c: No such file or directory
> 
> Caused by commit 9599ec0471deae24044241e2173090d2cbc0e899 ("x86-64, mem:
> Convert memmove() to assembly file and fix return value bug") interacting
> with our build system.
> 
> After removing arch/x86/lib/.memmove_64.o.cmd (left over from the build
> before merging the tip tree) from my object tree, it built correctly.

I am still getting this (of course).

Michal, is there anything that the kbuild system can do for us here?
Basically we have changed from using a .c file to generate a .o to using
a .S but the build system does not regenerate the .cmd file.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

[kbuild] Re: linux-next: build failure after merge of the tip tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> On Mon, 31 Jan 2011 15:42:59 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> > 
> > x86_64-linux-gcc: arch/x86/lib/memmove_64.c: No such file or directory
> > 
> > Caused by commit 9599ec0471deae24044241e2173090d2cbc0e899 ("x86-64, mem:
> > Convert memmove() to assembly file and fix return value bug") interacting
> > with our build system.
> > 
> > After removing arch/x86/lib/.memmove_64.o.cmd (left over from the build
> > before merging the tip tree) from my object tree, it built correctly.
> 
> I am still getting this (of course).

You reported this as a -tip build failure - but it appears to be some sort of kbuild 
bug/artifact, right? There was a leftover .memmove_64.o.cmd file from an old tree.

When jumping between kernel versions via git checkout a 'make mrproper' is generally 
needed. In most cases 'make' will figure things out but it's not always guaranteed.

So for example there are version transitions where a stale include/asm links could 
cause build problems.

Thanks,

	Ingo

Re: [kbuild] Re: linux-next: build failure after merge of the tip tree

[Peter Zijlstra]

On Thu, 2011-02-17 at 13:43 +0100, Ingo Molnar wrote:
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi all,
> > 
> > On Mon, 31 Jan 2011 15:42:59 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > > failed like this:
> > > 
> > > x86_64-linux-gcc: arch/x86/lib/memmove_64.c: No such file or directory
> > > 
> > > Caused by commit 9599ec0471deae24044241e2173090d2cbc0e899 ("x86-64, mem:
> > > Convert memmove() to assembly file and fix return value bug") interacting
> > > with our build system.
> > > 
> > > After removing arch/x86/lib/.memmove_64.o.cmd (left over from the build
> > > before merging the tip tree) from my object tree, it built correctly.
> > 
> > I am still getting this (of course).
> 
> You reported this as a -tip build failure - but it appears to be some sort of kbuild 
> bug/artifact, right? There was a leftover .memmove_64.o.cmd file from an old tree.
> 
> When jumping between kernel versions via git checkout a 'make mrproper' is generally 
> needed. In most cases 'make' will figure things out but it's not always guaranteed.
> 
> So for example there are version transitions where a stale include/asm links could 
> cause build problems.

Yeah, I run into this problem once every few days, totally annoying. A
make clean does fix it so I couldn't be arsed to actually submit myself
to Kbuild voodoo, but if someone who knows about that stuff could come
up with a fix I'd be most obliged.

Re: linux-next: build failure after merge of the tip tree

[Michal Marek]

On 17.2.2011 04:47, Stephen Rothwell wrote:
> Hi all,
> 
> On Mon, 31 Jan 2011 15:42:59 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
>> failed like this:
>>
>> x86_64-linux-gcc: arch/x86/lib/memmove_64.c: No such file or directory
>>
>> Caused by commit 9599ec0471deae24044241e2173090d2cbc0e899 ("x86-64, mem:
>> Convert memmove() to assembly file and fix return value bug") interacting
>> with our build system.
>>
>> After removing arch/x86/lib/.memmove_64.o.cmd (left over from the build
>> before merging the tip tree) from my object tree, it built correctly.
> 
> I am still getting this (of course).
> 
> Michal, is there anything that the kbuild system can do for us here?
> Basically we have changed from using a .c file to generate a .o to using
> a .S but the build system does not regenerate the .cmd file.

_Maybe_ we could work around it by letting fixdep remove the actual
source file from the list of dependencies in the .cmd file. The
dependency on the .c / .S / whatever file is given by the Makefiles, the
.cmd file is only needed for additional dependencies on headers. Let's
see what else breaks then ;).

Michal

Re: linux-next: build failure after merge of the tip tree

[Michal Marek]

On Thu, Feb 17, 2011 at 02:18:18PM +0100, Michal Marek wrote:
> On 17.2.2011 04:47, Stephen Rothwell wrote:
> > Hi all,
> > 
> > On Mon, 31 Jan 2011 15:42:59 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>
> >> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> >> failed like this:
> >>
> >> x86_64-linux-gcc: arch/x86/lib/memmove_64.c: No such file or directory
> >>
> >> Caused by commit 9599ec0471deae24044241e2173090d2cbc0e899 ("x86-64, mem:
> >> Convert memmove() to assembly file and fix return value bug") interacting
> >> with our build system.
> >>
> >> After removing arch/x86/lib/.memmove_64.o.cmd (left over from the build
> >> before merging the tip tree) from my object tree, it built correctly.
> > 
> > I am still getting this (of course).
> > 
> > Michal, is there anything that the kbuild system can do for us here?
> > Basically we have changed from using a .c file to generate a .o to using
> > a .S but the build system does not regenerate the .cmd file.
> 
> _Maybe_ we could work around it by letting fixdep remove the actual
> source file from the list of dependencies in the .cmd file. The
> dependency on the .c / .S / whatever file is given by the Makefiles, the
> .cmd file is only needed for additional dependencies on headers. Let's
> see what else breaks then ;).

It seems to work for me. Can you try the patch below? It needs to be
applied before merging 9599ec0 to have any effect.

Michal

From: Michal Marek <mmarek@suse.cz>
Subject: [PATCH] fixdep: Do not record dependency on the source file itself

The dependency is already expressed by the Makefiles, storing it in the
.cmd file breaks build if a .c file is replaced by .S or vice versa,
because the .cmd file contains

foo/bar.o: foo/bar.c ...

foo/bar.c ... :

so the foo/bar.c -> foo/bar.o rule triggers even if there is no
foo/bar.c anymore.

Signed-off-by: Michal Marek <mmarek@suse.cz>

diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index c9a16ab..9264725 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -315,6 +315,7 @@ static void parse_dep_file(void *map, size_t len)
 	char *end = m + len;
 	char *p;
 	char s[PATH_MAX];
+	int first;
 
 	p = strchr(m, ':');
 	if (!p) {
@@ -327,6 +328,7 @@ static void parse_dep_file(void *map, size_t len)
 
 	clear_config();
 
+	first = 1;
 	while (m < end) {
 		while (m < end && (*m == ' ' || *m == '\\' || *m == '\n'))
 			m++;
@@ -340,9 +342,16 @@ static void parse_dep_file(void *map, size_t len)
 		if (strrcmp(s, "include/generated/autoconf.h") &&
 		    strrcmp(s, "arch/um/include/uml-config.h") &&
 		    strrcmp(s, ".ver")) {
-			printf("  %s \\\n", s);
+			/* Do not output the first dependency (the
+			 * source file), so that kbuild is not confused
+			 * if a .c file is rewritten into .S or vice
+			 * versa.
+			 */
+			if (!first)
+				printf("  %s \\\n", s);
 			do_config_file(s);
 		}
+		first = 0;
 		m = p + 1;
 	}
 	printf("\n%s: $(deps_%s)\n\n", target, target);

Re: linux-next: build failure after merge of the tip tree

[Ingo Molnar]

* Michal Marek <mmarek@suse.cz> wrote:

> @@ -340,9 +342,16 @@ static void parse_dep_file(void *map, size_t len)
>  		if (strrcmp(s, "include/generated/autoconf.h") &&
>  		    strrcmp(s, "arch/um/include/uml-config.h") &&
>  		    strrcmp(s, ".ver")) {
> -			printf("  %s \\\n", s);
> +			/* Do not output the first dependency (the
> +			 * source file), so that kbuild is not confused
> +			 * if a .c file is rewritten into .S or vice
> +			 * versa.
> +			 */

Just a really minor nitpick, please use the standard comment style:

  /*
   * Comment .....
   * ...... goes here.
   */

specified in Documentation/CodingStyle.

Thanks,

	Ingo

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 872 bytes --]

Hi Michal,

On Thu, 17 Feb 2011 16:02:00 +0100 Michal Marek <mmarek@suse.cz> wrote:
>
> > _Maybe_ we could work around it by letting fixdep remove the actual
> > source file from the list of dependencies in the .cmd file. The
> > dependency on the .c / .S / whatever file is given by the Makefiles, the
> > .cmd file is only needed for additional dependencies on headers. Let's
> > see what else breaks then ;).
> 
> It seems to work for me. Can you try the patch below? It needs to be
> applied before merging 9599ec0 to have any effect.

Thanks, I will apply this as a fix on top of Linus' tree before I merge
anything else.  It looks simple enough that Linus may take it as a fix
right now.   Better to convince ourselves first, though, right?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]

Hi Michal,

On Fri, 18 Feb 2011 09:47:54 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Thu, 17 Feb 2011 16:02:00 +0100 Michal Marek <mmarek@suse.cz> wrote:
> >
> > > _Maybe_ we could work around it by letting fixdep remove the actual
> > > source file from the list of dependencies in the .cmd file. The
> > > dependency on the .c / .S / whatever file is given by the Makefiles, the
> > > .cmd file is only needed for additional dependencies on headers. Let's
> > > see what else breaks then ;).
> > 
> > It seems to work for me. Can you try the patch below? It needs to be
> > applied before merging 9599ec0 to have any effect.
> 
> Thanks, I will apply this as a fix on top of Linus' tree before I merge
> anything else.  It looks simple enough that Linus may take it as a fix
> right now.   Better to convince ourselves first, though, right?

That patch fixed the problem for me and has caused no obvious problems.

Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]