On Jan 31, 2013, at 10:50 PM, Bruce Ashfield <bruce.ashfi...@windriver.com> wrote:
> On 13-01-23 10:17 AM, Patrick Turley wrote: >> >> On Jan 23, 2013, at 7:48 AM, Bruce Ashfield<bruce.ashfi...@windriver.com> >> wrote: >>> On 13-01-23 12:34 AM, Patrick Turley wrote: >>>> >>>> On Jan 22, 2013, at 11:17 PM, Bruce Ashfield<bruce.ashfi...@windriver.com> >>>> wrote: >>>> >>>>> On 13-01-23 12:14 AM, Patrick Turley wrote: >>>>>> On Jan 22, 2013, at 10:43 PM, Bruce >>>>>> Ashfield<bruce.ashfi...@windriver.com> wrote: >>>>>>> On 13-01-22 9:26 PM, Patrick Turley wrote: >>> >>> Argh. I'll have to just run the commands myself and stop spamming the >>> list with ideas :) It's just a matter of making lkc accept the defaults >>> (i.e. you could also use allyesconfig, or allnoconfig) or even better >>> not trigger that config check at all. >> >> You're very kind to have spent so much time on my problem already. I look >> forward to hearing back. > > I'm not sure if you are still interested in this topic, but I took > a few minutes to look into this more today .. just to understand > exactly what is happening. > > It is what was discussed on the thread already, when you invoke > make scripts, there is an explicit dependency on auto.conf and > that is what triggers the make oldconfig if the .config is newer > than it is. Technically we are safe from this, assuming that the > .config and captured auto.conf match, and that auto.conf is in the > SDK. > > The other way that oldconfig is triggered in my experience (and > testing today) is what we mentioned before. If your .config was > generated with ARCH=<foo> (even ARCH=i386 the default) and you then > execute 'make scripts', you'll trigger the oldconfig. > > So to avoid it, you should execute your make scripts with ARCH=<your arch> > on the command line. > > As for saving ARCH in the .config, it has been considered in the past, > but never implemented. Other elements such as CROSS_COMPILE are now > saved, but not ARCH= since it isn't directly used in the .config, it's > a Makefile construct. 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 yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto