<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/4.6.1">
</HEAD>
<BODY>
While, I'm not an expert, I would like to point out: <A HREF="http://kernel.org/doc/index-old.html">http://kernel.org/doc/index-old.html</A> (the new index references this but the information isn't on the new index page directly).<BR>
<BR>
One thing mentioned is that a make distclean is required for reasonable results between any run with different architectures. So you can't run a make scripts to get scripts for the local system in a build directory configured for cross compiling for the device and expect it to work correctly.<BR>
<BR>
Also, about the config prompts: during dependency checking, the .config file is validated, and if it fails validation, make oldconfig is run, as it assumes the config was pulled from a previous kernel version. Since a .config file is ARCH specific, it will almost always be invalid when checked against a different architecture, and thus fire off a make oldconfig. This is why you get prompted to answer questions when you do "make scripts" and have a .config for another architecture.<BR>
<BR>
Also, I suspect you need to ensure the cross compiler is being called when necessary for the make scripts. It looks like the errors are from passing arm gcc parameters to an x86 gcc. You can try "make ARCH=arm CROSS_COMPILE=/???/" instead, where /???/ is the prefix to your arm cross compiler. The kernel build actually uses both cross and non-cross compilers during build so you have some support tools compiled to run natively and others that run on the end machine, so you don't want to override CXX and C++ to be the cross compiler.<BR>
<BR>
<BR>
Brian<BR>
<BR>
On Sat, 2013-02-02 at 00:48 +0000, Patrick Turley wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
On Jan 31, 2013, at 10:50 PM, Bruce Ashfield <<A HREF="mailto:bruce.ashfield@windriver.com">bruce.ashfield@windriver.com</A>> wrote:
<FONT COLOR="#737373">> On 13-01-23 10:17 AM, Patrick Turley wrote:</FONT>
<FONT COLOR="#737373">>> </FONT>
<FONT COLOR="#737373">>> On Jan 23, 2013, at 7:48 AM, Bruce Ashfield<<A HREF="mailto:bruce.ashfield@windriver.com">bruce.ashfield@windriver.com</A>></FONT>
<FONT COLOR="#737373">>> wrote:</FONT>
<FONT COLOR="#737373">>>> On 13-01-23 12:34 AM, Patrick Turley wrote:</FONT>
<FONT COLOR="#737373">>>>> </FONT>
<FONT COLOR="#737373">>>>> On Jan 22, 2013, at 11:17 PM, Bruce Ashfield<<A HREF="mailto:bruce.ashfield@windriver.com">bruce.ashfield@windriver.com</A>> wrote:</FONT>
<FONT COLOR="#737373">>>>> </FONT>
<FONT COLOR="#737373">>>>>> On 13-01-23 12:14 AM, Patrick Turley wrote:</FONT>
<FONT COLOR="#737373">>>>>>> On Jan 22, 2013, at 10:43 PM, Bruce Ashfield<<A HREF="mailto:bruce.ashfield@windriver.com">bruce.ashfield@windriver.com</A>> wrote:</FONT>
<FONT COLOR="#737373">>>>>>>> On 13-01-22 9:26 PM, Patrick Turley wrote:</FONT>
<FONT COLOR="#737373">>>> </FONT>
<FONT COLOR="#737373">>>> Argh. I'll have to just run the commands myself and stop spamming the</FONT>
<FONT COLOR="#737373">>>> list with ideas :) It's just a matter of making lkc accept the defaults</FONT>
<FONT COLOR="#737373">>>> (i.e. you could also use allyesconfig, or allnoconfig) or even better</FONT>
<FONT COLOR="#737373">>>> not trigger that config check at all.</FONT>
<FONT COLOR="#737373">>> </FONT>
<FONT COLOR="#737373">>> You're very kind to have spent so much time on my problem already. I look forward to hearing back.</FONT>
<FONT COLOR="#737373">> </FONT>
<FONT COLOR="#737373">> I'm not sure if you are still interested in this topic, but I took</FONT>
<FONT COLOR="#737373">> a few minutes to look into this more today .. just to understand</FONT>
<FONT COLOR="#737373">> exactly what is happening.</FONT>
<FONT COLOR="#737373">> </FONT>
<FONT COLOR="#737373">> It is what was discussed on the thread already, when you invoke</FONT>
<FONT COLOR="#737373">> make scripts, there is an explicit dependency on auto.conf and</FONT>
<FONT COLOR="#737373">> that is what triggers the make oldconfig if the .config is newer</FONT>
<FONT COLOR="#737373">> than it is. Technically we are safe from this, assuming that the</FONT>
<FONT COLOR="#737373">> .config and captured auto.conf match, and that auto.conf is in the</FONT>
<FONT COLOR="#737373">> SDK.</FONT>
<FONT COLOR="#737373">> </FONT>
<FONT COLOR="#737373">> The other way that oldconfig is triggered in my experience (and</FONT>
<FONT COLOR="#737373">> testing today) is what we mentioned before. If your .config was</FONT>
<FONT COLOR="#737373">> generated with ARCH=<foo> (even ARCH=i386 the default) and you then</FONT>
<FONT COLOR="#737373">> execute 'make scripts', you'll trigger the oldconfig.</FONT>
<FONT COLOR="#737373">> </FONT>
<FONT COLOR="#737373">> So to avoid it, you should execute your make scripts with ARCH=<your arch></FONT>
<FONT COLOR="#737373">> on the command line.</FONT>
<FONT COLOR="#737373">> </FONT>
<FONT COLOR="#737373">> As for saving ARCH in the .config, it has been considered in the past,</FONT>
<FONT COLOR="#737373">> but never implemented. Other elements such as CROSS_COMPILE are now</FONT>
<FONT COLOR="#737373">> saved, but not ARCH= since it isn't directly used in the .config, it's</FONT>
<FONT COLOR="#737373">> a Makefile construct.</FONT>
I absolutely *am* still interested in this issue, and thank you for taking another look.
There are two commands that I'm interested in executing:
-- make oldconfig
-- make scripts
(Since I install the SDK under /opt, I use sudo when running these commands, but I don't *think* that's important.)
Here's what happens with the first command:
$ sudo make oldconfig ARCH=arm
HOSTCC scripts/basic/fixdep
HOSTCC scripts/basic/docproc
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/kxgettext.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/lex.zconf.c
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf --oldconfig Kconfig
#
# configuration written to .config
#
As you say, adding "ARCH=arm" puts the build at ease and it completes just fine.
Here's what happens with the second command:
$ sudo make scripts ARCH=arm
scripts/kconfig/conf --silentoldconfig Kconfig
HOSTCC scripts/genksyms/genksyms.o
SHIPPED scripts/genksyms/lex.c
SHIPPED scripts/genksyms/parse.h
SHIPPED scripts/genksyms/keywords.c
HOSTCC scripts/genksyms/lex.o
SHIPPED scripts/genksyms/parse.c
HOSTCC scripts/genksyms/parse.o
HOSTLD scripts/genksyms/genksyms
CC scripts/mod/empty.o
cc1: error: unrecognized command line option "-mlittle-endian"
cc1: error: unrecognized command line option "-mapcs"
cc1: error: unrecognized command line option "-mno-sched-prolog"
cc1: error: unrecognized command line option "-mabi=aapcs-linux"
cc1: error: unrecognized command line option "-mno-thumb-interwork"
scripts/mod/empty.c:1: error: bad value (armv5t) for -march= switch
scripts/mod/empty.c:1: error: bad value (armv5t) for -mtune= switch
make[2]: *** [scripts/mod/empty.o] Error 1
make[1]: *** [scripts/mod] Error 2
make: *** [scripts] Error 2
Recall that, when I do *not* give the "ARCH=arm" argument, I get reams of config questions, but the build works.
This is an improvement in that the config questions are gone but, of course, the build fails.
Perhaps it *should* fail. Perhaps I'm doing something that actually doesn't make sense. Or perhaps I'm doing something that Yocto just isn't ready to support. At this point, I should say:
1) I have a workaround for all this, so I am *not* dead in the water.
2) I am a kernel building n00b and it legitimately may not be worth your time (or anyone else's) to continue to look at this until I "catch up." I don't want anyone throwing up their hands in frustration and saying "Doesn't this guy know anything?" It's perfectly reasonable to cut me off at this point :)
_______________________________________________
yocto mailing list
<A HREF="mailto:yocto@yoctoproject.org">yocto@yoctoproject.org</A>
<A HREF="https://lists.yoctoproject.org/listinfo/yocto">https://lists.yoctoproject.org/listinfo/yocto</A>
</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>