On Tue, 30 Apr 2002 10:45:43 +0200,
"Arnd Bergmann" <[EMAIL PROTECTED]> wrote:
>kaos wrote
>> Not necessary. Use vmlinux.lds.S and no vmlinux.lds.i file. kbuild
>> 2.5 automatically builds .i files from .S and tracks the config
>> dependencies. If it does not track them, it is a bug.
>I just tried renaming vmlinux.lds.S to vmlinux.lds.c, but the results are
>identical, so
>it's not a bug with CONFIG_* dependencies in .S files.
>If I add 'select(vmlinux.lds.o)' to my Makefile.in, the dependency checking
>works fine, but of course the link will fail...
It's a bug. pp_makefile4 detected that a config option used in .S had
changed but did not propagate that change onto the .i file, because the
.i file was not select()ed. Patch against core-8.
--- 2.5.11-kbuild-2.5-core/scripts/pp_makefile4.c Sat Apr 27 15:57:29 2002
+++ 2.5.11-kbuild-2.5/scripts/pp_makefile4.c Tue Apr 30 19:45:31 2002
@@ -2153,7 +2153,8 @@ check_uptodate_run(PPDB * db, kvpair kv,
return (0);
}
t = (DB_REC_TARGET *) (kv.val.dptr);
- if (!t->flags.sely_summary && !t->flags.selm_summary) {
+ if (!t->flags.sely_summary && !t->flags.selm_summary &&
+ !t->flags.gen_i && !t->flags.gen_s) {
return (0);
}
relname = read_db_text(db, t->relname);
>> You cannot use the same object tree for two different architectures,
>> you need separate objtrees. In particular the kbuild database which
>> lives in objtree is persistent and still contains data for the other
>> architecture.
>Yes, that's fine. Still, I would prefer kbuild to either give an error
>message or to rebuild the objtree whenever someone tries this instead
>of simply making the tree unusable.
>Of course there is not much use trying to reuse an objtree for different
>archs, but it happened to me more than once that I mistyped the
>architecture
>name after alternating between s390 and s390x for a few hours...
It is on my FIXME list, to track critical config options and force a
rebuild if any of them change. ARCH is one of the critical options,
see the end of arch/i386/boot/config.install-2.5. I wanted a kbuild
system that was as close as possible to the existing process, without
imposing any new restrictions. Once kbuild 2.5 is in Linus's kernel,
then we can tie up the loose ends.
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
