Re: Build external module against Yocto kernel

[Bruce Ashfield <bruce.ashfield@windriver.com>]

On 13-01-22 03:28 PM, Patrick Turley wrote:
> On Jan 16, 2013, at 11:11 AM, Darren Hart <dvhart@linux.intel.com> wrote:
>> On 01/15/2013 10:38 AM, Bruce Ashfield wrote:
>>> I finally found the entries that I was recalling earlier. They are:
>>>
>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=241
>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614
>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=2968
>>>
>>> 1614 and 2968 are the most interesting for what you are asking.
>>>
>>> As you can see the net result of those bugs is that you can get the
>>> right parts of the kernel tree in SDK packages, since they include
>>> dev packages, and with what is currently in kernel-dev .. it should
>>> be enough to build against in the SDK (perhaps with just the LDFLAGS
>>> tweaks mentioned in the other thread). The sources should be part
>>> of the sysroot, and hence available when that is packaged for use
>>> outside of bitbake/yocto.
>>>
>>> If you aren't seeing kernel-dev in the SDK image, it might be that
>>> TOOLCHAIN_TARGET_TASK doesn't have kernel-dev by default, or something
>>> else is different in the SDK that is being generated in your testing.
>>>
>>> I'm only speculating about what might be missing, since I'm not 100%
>>> familiar with the SDK, but perhaps Jessica or others can chime in if
>>> I've led you astray :)
>
> You have *not* led me astray. A fundamental problem was that I didn't comprehend the distinction/correspondence between "target image" recipes and "SDK image" recipes. I believe I get that now.
>
> We've created a target image recipe, and an SDK image recipe that "require's" the former (this is conventional, I believe). The SDK image recipe adds all the development packages and, yes, it includes kernel-dev. So, when I install my SDK now, I certainly *do* get all the kernel header files. As you know, I do *not* get the hostprogs.
>
> As I described in an earlier post, I am currently reaching into the "tmp" directory, pulling out the kernel work directory, and making it directly available to my external build process. This solves my problem because the work directory contains all the header files I need *and* the hostprogs. Of course, it's "bad" because it's not an intended way to use the build artifacts, and it's awkward to distribute.
>
> With the recent improvement, I can now get the kernel header files packaged in the SDK. That's good because it's an intended mechanism and it's easy to distribute.
>
> With regard to:
>
>      https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614
>
> This seems a reasonable solution to the problem of building modules on the target, given the difficulties of dealing with executables. I'm not building modules on the target (I'm cross-compiling them), but this seems to apply anyway. It adds an extra step to SDK installation, but that's the least of our problems.
>
> One problem I ran into … When I tried to execute "make scripts," I got a whole bunch of config questions that I *think* should have been answered with a .config file or something. Should I have copied out the .config file from the kernel work directory into the SDK installation before I ran that? Is that the "best" way to get around all the questions?
>

Interesting. I haven't seen this myself, so just a couple of quick
questions:

   - without the .config, did you still get a working set of hostprogs, and
     only had to suffer the warnings ?

   - If the answer is yes, then the .config really doesn't matter for this
     and the approach of grabbing a .config should work fine or even
     having a dummy defconfig available with enough to keep the build
     happy.

Definitely sounds like something we can address and it's worth putting into
bugzilla so it doesn't get lost.

Bruce

>> Patrick, please keep us posted if this continues to not work for you. I
>> will open a bug to include a section about this in the kernel
>> development manual.
>
> It's very *nearly* working for me now. See my question above.
>