On 13-01-22 03:28 PM, Patrick Turley wrote:
On Jan 16, 2013, at 11:11 AM, Darren Hart <dvh...@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.
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
