[yocto] Build external module against Yocto kernel

[Patrick Turley]

On Jan 31, 2013, at 10:50 PM, Bruce Ashfield <bruce.ashfield at windriver.com> wrote:

> On 13-01-23 10:17 AM, Patrick Turley wrote:
>> 
>> On Jan 23, 2013, at 7:48 AM, Bruce Ashfield<bruce.ashfield at windriver.com>
>>  wrote:
>>> On 13-01-23 12:34 AM, Patrick Turley wrote:
>>>> 
>>>> On Jan 22, 2013, at 11:17 PM, Bruce Ashfield<bruce.ashfield at windriver.com>  wrote:
>>>> 
>>>>> On 13-01-23 12:14 AM, Patrick Turley wrote:
>>>>>> On Jan 22, 2013, at 10:43 PM, Bruce Ashfield<bruce.ashfield at 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 :)