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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 17 Feb 2011 16:02:00 +0100
From:	Michal Marek <mmarek@...e.cz>
To:	Stephen Rothwell <sfr@...b.auug.org.au>
Cc:	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>,
	"H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Fenghua Yu <fenghua.yu@...el.com>
Subject: Re: linux-next: build failure after merge of the tip tree

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@...b.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@...e.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@...e.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);
--
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/