[yocto] Shouldn't linux/version.h appear in the SDK's host sysroot?
I'm using a Yocto-based SDK, produced by: bitbake meta-toolchain-sdk This creates the file poky-eglibc-x86_64-arm-toolchain-gmae-1.3.sh in the directory build/tmp/deploy/sdk I ran the installation script to install the SDK on my build system. Within the SDK installation directory, under "sysroots", I have the following two directories: armv7a-vfp-neon-poky-linux-gnueabi x86_64-pokysdk-linux Unless I'm mistaken, the first one reflects the target environment, and the second one contains what I need to do cross-compilation. Thus, the latter contains the cross-compilation tools, and that's the sysroot to which all my builds are directed. I'm compiling the lm_sensors package for my target. As part of its work, it tries to discover the version of the target linux kernel. To do this, it compiles a very small file (etc/config.c) that includes the header file . As it happens, does *not* appear in the cross-compilation sysroot, so this simple task fails. That header file *does* appear in the target sysroot, but that's of no use to me in the cross-compilation process. I believe one of the following is true: 1) The lm_sensors package is doing something entirely legitimate, and the file *should* appear in the cross-compilation sysroot to support this. The Yocto SDK build target needs a small fix so that is properly added to the cross-compilation sys root. In the meantime, I can work around this oversight by creating a symbolic link. 2) I've made a mistake in setting up my build environment because I don't understand how cross-compilation *should* be done. If done properly, the cross-compilation process will have access to *both* sysroots and get what it needs from each. If this is the case, please tell me what I appear to have done wrong. 3) Something else. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Build external module against Yocto kernel
I have to build a module from a third-party that has nothing to do with Yocto. I want to build this module against the kernel Yocto is giving me. The Make file for this module has a build command like this: make -C $(LINUX_DIR) M=`pwd` $(ENV) \ EXTRA_CFLAGS="$(EXTRA_CFLAGS)" modules Obviously, this command needs to connect with either the Linux source tree or something like a "kernel-headers" package. I used the meta-toolchain-sdk recipe to produce an SDK, and I installed it. Unfortunately, I don't see a "kernel-header" equivalent in there. This leads me to imagine I must point this command at some sub-tree within the Yocto output (probably under tmp/sysroots). And, if I want that tree available elsewhere, I have to package it up into a tarball and transport it. Usually, Yocto is way ahead of me on these sorts of things, and there's already a graceful way to deal with this -- I just haven't figure it out yet. What am I missing? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] SDK environment LDFLAGS problem?
I used the meta-toolchain-sdk recipe to produce an SDK, and I installed it. Here's an interesting line from the environment setup script: export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed" All these linker options are preceded by "-Wl", which indicates the SDK is *expecting* them to be given to gcc and then passed on to ld. If you look at the help for the ld command line, all these options are available, but with the "-Wl," omitted. In fact, if you use these options exactly as shown here, ld will complain that they aren't recognized and fail. So, the SDK is giving me a value of LDFLAGS that *cannot* be used with ld. Of course, the C compiler driver can link and produce executables, and that muddies the issue somewhat. Here's an example where this is causing me real problems… I'm building an external module against the kernel produced by Yocto. Here's an extract from my output: make -C /home/pturley/yocto-mpu-build/tmp/work/dm8148_mpu-poky-linux-gnueabi/linux-ti81xx-psp-2.6.37-r0+spawnlabs+r0/git M=`pwd` ARCH=arm CROSS_COMPILE=/opt/poky/1.3/sysroots/x86_64-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi- \ EXTRA_CFLAGS="-DUSE_UDEV=1 -DMAX_POOLS=128" modules . . . LD [M] /home/pturley/z3-work/z3-centaurus-dm814x_RPS-20120626/ezsdk/component-sources/linuxutils_3_22_00_02/packages/ti/sdo/linuxutils/cmem/src/module/cmemk.ko /opt/poky/1.3/sysroots/x86_64-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-ld: unrecognized option '-Wl,-O1' As you can see here, the kernel Make files are interpreting LDFLAGS as something that *can* be given directly to ld, so they fail. My questions are: 1) Has anyone else run into this before? 2) If so, how did you resolve it? 3) Since the Yocto kernel build is *not* failing, I infer that it is *not* using the ld options the SDK gives me. So, the Yocto kernel build has its own pathway through which it computes its value for LDFLAGS. Why would Yocto use its own SDK in a way that no user is expected to? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build external module against Yocto kernel
Thank you for directing me toward that documentation. As it happens, I have already read that, and it doesn't apply. The section you mentioned begins with this text: While it is always preferable to work with sources integrated into the Linux kernel sources, if you need an external kernel module, the hello-mod.bb recipe is available as a template from which you can create your own out-of-tree Linux kernel module recipe. The approach here is to create a recipe that will build a module outside the kernel tree, but still within the Yocto system. That isn't what I'm doing. I have source code for a kernel module that is entirely outside Yocto. I'm *not* going to write a recipe for this module and integrate it into a Yocto layer. Here's a link to instructions on how I would do this in Ubuntu: http://www.cyberciti.biz/tips/build-linux-kernel-module-against-installed-kernel-source-tree.html As you can see, Ubuntu (and, of course, other major distributions) have "kernel-headers" packages that carry all the artifacts one needs to build a module "after the fact." Does Yocto have a mechanism for packaging up the necessary artifacts and making them available *outside* the Yocto build system and long *after* the Yocto build is finished? Does Yocto recognize the necessity of this? The best I've been able to do is point my module build process at something like this: LINUX_DIR=/home/pturley/yocto-mpu-build/tmp/work/dm8148_mpu-poky-linux-gnueabi/linux-ti81xx-psp-2.6.37-r0+spawnlabs+r0/git This works but it's messy, unreliable and inconvenient. So, my question remains: Does Yocto have a graceful way of dealing with this situation, perhaps like Ubuntu and friends? On Jan 15, 2013, at 11:09 AM, Brian Lloyd mailto:bll...@familyhonor.net>> wrote: Or better yet, now that it is past initial, use http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules. <http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules.%C2%A0> :) It worked fine for 1.2 (denzil) for me, though it is written for a later one. Brian On Tue, 2013-01-15 at 11:07 -0600, Brian Lloyd wrote: Try this in work documentation and let us know how it helps or if there is something missing that would help more: http://www.yoctoproject.org/docs/hart/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules I just did the exact same thing and was happy to discover there is support in yocto for doing just this. Brian On Mon, 2013-01-14 at 23:27 +, Patrick Turley wrote: I have to build a module from a third-party that has nothing to do with Yocto. I want to build this module against the kernel Yocto is giving me. The Make file for this module has a build command like this: make -C $(LINUX_DIR) M=`pwd` $(ENV) \ EXTRA_CFLAGS="$(EXTRA_CFLAGS)" modules Obviously, this command needs to connect with either the Linux source tree or something like a "kernel-headers" package. I used the meta-toolchain-sdk recipe to produce an SDK, and I installed it. Unfortunately, I don't see a "kernel-header" equivalent in there. This leads me to imagine I must point this command at some sub-tree within the Yocto output (probably under tmp/sysroots). And, if I want that tree available elsewhere, I have to package it up into a tarball and transport it. Usually, Yocto is way ahead of me on these sorts of things, and there's already a graceful way to deal with this -- I just haven't figure it out yet. What am I missing? ___ yocto mailing list yocto@yoctoproject.org<mailto:yocto@yoctoproject.org> https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org<mailto:yocto@yoctoproject.org> https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] SDK environment LDFLAGS problem?
On Jan 15, 2013, at 11:38 AM, Brian Lloyd mailto:bll...@familyhonor.net>> wrote: The kernel is a special case, where the SDK is really designed for developing user applications (which the kernel is not). Yes, it's clear to me that, in this one respect, the SDK is unsuitable for building kernels or kernel modules. My point is that this is a problem, and it might be reasonable to fix it. I found it pretty easy to create a kernel-module-MYMODULE.bbclass file and build the kernel and module in the OE/Poky build system directly, and then have it included in the image made for the device. See http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules for details. Thanks for pointing me at that. As it happens, I can't use that method because I'm not going to create a recipe. Brian On Tue, 2013-01-15 at 16:52 +, Patrick Turley wrote: I used the meta-toolchain-sdk recipe to produce an SDK, and I installed it. Here's an interesting line from the environment setup script: export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed" All these linker options are preceded by "-Wl", which indicates the SDK is *expecting* them to be given to gcc and then passed on to ld. If you look at the help for the ld command line, all these options are available, but with the "-Wl," omitted. In fact, if you use these options exactly as shown here, ld will complain that they aren't recognized and fail. So, the SDK is giving me a value of LDFLAGS that *cannot* be used with ld. Of course, the C compiler driver can link and produce executables, and that muddies the issue somewhat. Here's an example where this is causing me real problems… I'm building an external module against the kernel produced by Yocto. Here's an extract from my output: make -C /home/pturley/yocto-mpu-build/tmp/work/dm8148_mpu-poky-linux-gnueabi/linux-ti81xx-psp-2.6.37-r0+spawnlabs+r0/git M=`pwd` ARCH=arm CROSS_COMPILE=/opt/poky/1.3/sysroots/x86_64-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi- \ EXTRA_CFLAGS="-DUSE_UDEV=1 -DMAX_POOLS=128" modules . . . LD [M] /home/pturley/z3-work/z3-centaurus-dm814x_RPS-20120626/ezsdk/component-sources/linuxutils_3_22_00_02/packages/ti/sdo/linuxutils/cmem/src/module/cmemk.ko /opt/poky/1.3/sysroots/x86_64-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-ld: unrecognized option '-Wl,-O1' As you can see here, the kernel Make files are interpreting LDFLAGS as something that *can* be given directly to ld, so they fail. My questions are: 1) Has anyone else run into this before? 2) If so, how did you resolve it? 3) Since the Yocto kernel build is *not* failing, I infer that it is *not* using the ld options the SDK gives me. So, the Yocto kernel build has its own pathway through which it computes its value for LDFLAGS. Why would Yocto use its own SDK in a way that no user is expected to? ___ yocto mailing list yocto@yoctoproject.org<mailto:yocto@yoctoproject.org> https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build external module against Yocto kernel
On Jan 15, 2013, at 12:00 PM, Bruce Ashfield wrote: > On 13-01-15 12:54 PM, Patrick Turley wrote: >> Thank you for directing me toward that documentation. As it happens, I >> have already read that, and it doesn't apply. > > There are ways to do this, your requirement is the same as the on-target > module building requirement. Have enough of the kernel source packaged > to build modules on the target, after it has booted. Well, I still want to cross-compile them, but I see your point. > The trick is packaging things properly to not get binary/target elements > in the SDK/native packages, and to package just enough for the build. But > the issues have been explored and there was a plan. I know that Darren > (cc'd) has looked into this more than I have recently. > > I can't locate the bugzilla entries on this at the moment, but I recall > that some parts were still missing, but may be addressed in yocto 1.4, > when I find the bug numbers, I'll have a better idea. As I expected, someone else has already thought about this. This isn't the most common approach so it makes sense that it's been a lower priority. The good news for me is that I know I'm not missing something, so I can stop looking for it. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build external module against Yocto kernel
On Jan 16, 2013, at 11:11 AM, Darren Hart 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 :) >> > > Thanks for keeping this going Bruce. Yes, kernel-dev is the package for > the target. The only trick here is that we currently purge the host > binaries which means that you need to build scripts on the target prior > to building the module. > > I think this might be missing from the new kernel manual as it isn't a > particularly common use-case, and is rather orthogonal to the way the > tooling has been designed (not to say it can't be done). > > 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. I got sick and was also diverted to other things, so I apologize for not responding sooner. I am very appreciative of every CPU cycle you have all spent considering this issue -- I wouldn't want you to imagine otherwise. I will gladly have a look at those issues and absorb the information you've offered. I will also let you all know if it works for me. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Adding ALSA to the Yocto SDK
I've been working on re-targeting some code from a vendor's board to our own board. For libraries and other low-level code, everything's been fine. For test applications, I'm running into a dependency on the header file alsa/asoundlib.h, which is obviously part of ALSA. I've been building our SDK with: bitbake meta-toolchain-sdk This gives us most everything we need, but it does *not* include header files and libraries for ALSA. That actually seems perfectly reasonable to me -- not everyone needs ALSA support in their applications, so the *default* SDK shouldn't be burdened with that. We *do* need it. As I see it, there are two possibilities: 1) There's something I can do that will cause OE/Yocto to include ALSA header files in the SDK I produce. If that's the case, can you tell me what I need to do? 2) The ALSA header files aren't *supposed* to be in the SDK -- I'm supposed to be delivering them to the compilation process in another way. If that's the case, can you tell me what I need to do? Other items of note… -- Executing "bitbake alsa-lib" *did* put the expected files within our sysroot (under tmp/sysroots). Even so (as we intuitively expected) executing "bitbake meta-toolchain-sdk" afterward did *not* put them into the SDK. We conclude that having a package built and available for the SDK doesn't necessarily get it into the SDK. -- Adding ALSA to our image also caused the correct files to end up in our sysroot but, again, nothing appeared in the SDK. We conclude that the contents of the image do *not* dictate the contents of the SDK. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Adding ALSA to the Yocto SDK
On Jan 21, 2013, at 4:35 PM, "Zhang, Jessica" wrote: > Hi Patrick, > > Since you're able to add the dev packages to images, just do bitbake > yourimagewithALSA -c populate_sdk, that should generate a SDK contains ALSA. > By default, meta-toolchain-sdk is predefined unless you use "-c populate_sdk" > to enforce the SDK sysroot to match your rootfs. All the clues rolling in are starting to knit together. At first, I regarded the "populate_sdk" task as a hack, since it seemed to be expressing something that was naturally a "target" -- not a "task." Now I see that it is a way to connect an image to a corresponding SDK. That makes a *lot* more sense. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Adding ALSA to the Yocto SDK
On Jan 21, 2013, at 5:16 PM, Patrick Turley wrote: > On Jan 21, 2013, at 4:35 PM, "Zhang, Jessica" wrote: > >> Hi Patrick, >> >> Since you're able to add the dev packages to images, just do bitbake >> yourimagewithALSA -c populate_sdk, that should generate a SDK contains ALSA. >> By default, meta-toolchain-sdk is predefined unless you use "-c >> populate_sdk" to enforce the SDK sysroot to match your rootfs. > > > All the clues rolling in are starting to knit together. > > At first, I regarded the "populate_sdk" task as a hack, since it seemed to be > expressing something that was naturally a "target" -- not a "task." > > Now I see that it is a way to connect an image to a corresponding SDK. That > makes a *lot* more sense. One of my colleagues did some research on this and I believe we've found the best way for *us* to do this. We tried using a single image recipe. We tried both bitbake'ing this recipe directly *and* using the "populate_sdk" task with it. This gave us the SDK we needed, but it resulted in development header files appearing in the target root file system. Like core-image-sato and core-image-sato-sdk, we'll have have two images: 1) A target image recipe. We will bitbake this recipe directly to produce the target image. We will *never* use the "populate_sdk" task with this recipe. 2) An SDK image recipe. This recipe "require's" the target image recipe and adds various development packages to it. We will *never* bitbake this recipe directly because we have no interest in the root file system it would produce. We will *only* use the "populate_sdk" task with this recipe. This gives us the clean target root file system we need *and* the SDK we need. The disadvantage is that we have to keep two recipe files in sync with each other. Fortunately, these are low-frequency and low-volume changes, so we think this is a reasonable trade-off. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build external module against Yocto kernel
On Jan 15, 2013, at 1:16 PM, "Zhang, Jessica" wrote: > For your LDFLAGS question in another email thread, the yocto SDK is mainly > produced for application developer, but seems we are hearing more usage > request for it to support kernel module build as well. As Eric pointed, can > you just set LDFLAGS="" and we'll add that instruction to developer's manual? I *can* clear the LDFLAGS variable just before building modules against the kernel. That works. I understand history makes this difficult, and this is a problem OE/Yocto wasn't originally *intended* to solve. My use case in an outlier, and I don't presume to know what "should" be done. On the other hand, I wouldn't want anyone to feel that putting those instructions in the documentation is a "tidy" solution. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build external module against Yocto kernel
On Jan 16, 2013, at 11:11 AM, Darren Hart 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? > 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
Re: [yocto] Build external module against Yocto kernel
On Jan 22, 2013, at 2:34 PM, Bruce Ashfield wrote: > On 13-01-22 03:28 PM, Patrick Turley wrote: >> 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. Below, please find a transcript of the commands I executed. You'll see that I installed the SDK, tried to "make scripts," and then got attacked with a storm of config questions. I cut off the transcript at the second question, but there are dozens that follow. There *is* a .config file in the SDK directory, and it is identical to the one in our kernel build directory: /home/pturley/yocto-mpu-build/tmp/work/dm8148_mpu-poky-linux-gnueabi/linux-ti81xx-psp-2.6.37-r0+spawnlabs+r0/git Unfortunately, I'm still something of a n00b when it comes to building the kernel. I suspect *most* of these questions are irrelevant to hostprogs, but I can't say that *all* of them are. If I just hold down the "Enter" key, I believe all the defaults are taken, and I eventually *do* get hostprogs that execute, but I don't know if they're appropriate to my kernel. (Again, I'm a n00b, so perhaps there's no effect at all.) $ pwd /home/pturley/yocto-mpu-build/tmp/deploy/sdk $ ls poky-eglibc-x86_64-arm-toolchain-1.3.sh $ sudo ./poky-eglibc-x86_64-arm-toolchain-1.3.sh Enter target directory for SDK (default: /opt/poky/1.3): You are about to install the SDK to "/opt/poky/1.3". Proceed[Y/n]? Extracting SDK...done Setting it up...done SDK has been successfully set up and is ready to be used. $ cd /opt/poky/1.3/sysroots/dm8148_mpu-poky-linux-gnueabi/usr/src/kernel $ ls -a . firmware lib scripts .. fs MAINTAINERS security arch includeMakefilesound block init mm System.map-2.6.37 .configipcModule.symvers tools COPYINGKbuild net uImage CREDITSKconfigpatches usr crypto kernel README virt Documentation kernel-abiversion REPORTING-BUGS driverskernel-image-name samples $ sudo make scripts 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 --silentoldconfig Kconfig * * Restart config... * * * General setup * Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [Y/n/?] y Cross-compiler tool prefix (CROSS_COMPILE) [] Local version - append to kernel release (LOCALVERSION) [] Automatically append version information to the version string (LOCALVERSION_AUTO) [N/y/?] n Kernel compression mode > 1. Gzip (KERNEL_GZIP) 2. Bzip2 (KERNEL_BZIP2) (NEW) 3. LZMA (KERNEL_LZMA) 4. LZO (KERNEL_LZO) choice[1-4?]: Support for paging of anonymous memory (swap) (SWAP) [N/y/?] n System V IPC (SYSVIPC) [Y/n/?] y POSIX Message Queues (POSIX_MQUEUE) [Y/n/?] y BSD Process Accounting (BSD_PROCESS_ACCT) [Y/n/?] y BSD Process Accounting version 3 file format (BSD_PROCESS_ACCT_V3) [Y/n/?] y Export task/process statistics through netlink (EXPERIMENTAL) (TASKSTATS) [Y/n/?] y Enable per-task delay accounting (EXPERIMENTAL) (TASK_DELAY_ACCT) [Y/n/?] y Enable extended accounting over taskstats (EXPERIMENTAL) (TASK_XACCT) [Y/n/?] y Enable per-task storage I/O accounting (EXPERIMENTAL) (TASK_IO_ACCOUNTING) [Y/n/?] y Auditing support (AUDIT) [N/y/?] n Kernel .config support (IKCONFIG) [Y/n/m/?] y Enable access to .config through /proc/config.gz (IKCONFIG_PROC) [Y/n/?] y Kernel log buffer size (16 => 64KB, 17 => 128KB) (LOG_BUF_SHIFT) [17] 17 enable deprecated sysfs features to support old userspace tools (SYSFS_DEPRECATED) [N/y/?] n Kernel->user space relay suppo
Re: [yocto] Build external module against Yocto kernel
On Jan 22, 2013, at 10:43 PM, Bruce Ashfield wrote: > On 13-01-22 9:26 PM, Patrick Turley wrote: >> If I just hold down the "Enter" key, I believe all the defaults are taken, >> and I eventually *do* get hostprogs that execute, but I don't know if >> they're appropriate to my kernel. (Again, I'm a n00b, so perhaps there's no >> effect at all.) > > This will be fine, the defaults will work. The kernel build infrastructure > is picking up what it thinks is a change source -> to config and trying > to reconcile the differences. > > If you throw in a 'make oldconfig' before you do the 'make scripts', does > that quiet things down a bit ? No -- "make oldconfig" caused the very same questions (see below). --- $ cd /opt/poky/1.3/sysroots/dm8148_mpu-poky-linux-gnueabi/usr/src/kernel $ ls arch drivers Kbuild MAINTAINERS README System.map-2.6.37 block firmware KconfigMakefileREPORTING-BUGS tools COPYINGfskernel mm samples uImage CREDITSinclude kernel-abiversion Module.symvers scripts usr crypto init kernel-image-name net securityvirt Documentation ipc libpatches sound $ sudo make oldconfig 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 * * Restart config... * * * General setup * Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [Y/n/?] y Cross-compiler tool prefix (CROSS_COMPILE) [] Local version - append to kernel release (LOCALVERSION) [] Automatically append version information to the version string (LOCALVERSION_AUTO) [N/y/?] n Kernel compression mode > 1. Gzip (KERNEL_GZIP) 2. Bzip2 (KERNEL_BZIP2) (NEW) 3. LZMA (KERNEL_LZMA) 4. LZO (KERNEL_LZO) choice[1-4?]: ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build external module against Yocto kernel
On Jan 22, 2013, at 11:17 PM, Bruce Ashfield wrote: > On 13-01-23 12:14 AM, Patrick Turley wrote: >> On Jan 22, 2013, at 10:43 PM, Bruce Ashfield >> wrote: >>> On 13-01-22 9:26 PM, Patrick Turley wrote: >>>> If I just hold down the "Enter" key, I believe all the defaults are taken, >>>> and I eventually *do* get hostprogs that execute, but I don't know if >>>> they're appropriate to my kernel. (Again, I'm a n00b, so perhaps there's >>>> no effect at all.) >>> >>> This will be fine, the defaults will work. The kernel build infrastructure >>> is picking up what it thinks is a change source -> to config and trying >>> to reconcile the differences. >>> >>> If you throw in a 'make oldconfig' before you do the 'make scripts', does >>> that quiet things down a bit ? >> >> No -- "make oldconfig" caused the very same questions (see below). > > Aha. of course (now that I think about it), the build was simply triggering > old config automatically. > > silentoldconfig is what I really should have typed :) Nope - still doesn't work. $ sudo make silentoldconfig 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 --silentoldconfig Kconfig * * Restart config... * * * General setup * Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [Y/n/?] y Cross-compiler tool prefix (CROSS_COMPILE) [] Local version - append to kernel release (LOCALVERSION) [] Automatically append version information to the version string (LOCALVERSION_AUTO) [N/y/?] n Kernel compression mode > 1. Gzip (KERNEL_GZIP) 2. Bzip2 (KERNEL_BZIP2) (NEW) 3. LZMA (KERNEL_LZMA) 4. LZO (KERNEL_LZO) choice[1-4?]: ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build external module against Yocto kernel
On Jan 23, 2013, at 7:48 AM, Bruce Ashfield wrote: > On 13-01-23 12:34 AM, Patrick Turley wrote: >> >> On Jan 22, 2013, at 11:17 PM, Bruce Ashfield >> wrote: >> >>> On 13-01-23 12:14 AM, Patrick Turley wrote: >>>> On Jan 22, 2013, at 10:43 PM, Bruce Ashfield >>>> 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. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Inconsistency in the SDK
Here's our machine in local.conf: MACHINE = "dm8148-mpu" Naturally, then, we see a directly like this under tmp/work: dm8148_mpu-poky-linux-gnueabi Also, under tmp/sysroots, we see these two: dm8148-mpu dm8148-mpu-tcbootstrap Finally, when I install the SDK, I see the following under sysroots: dm8148_mpu-poky-linux-gnueabi x86_64-pokysdk-linux However, if I ask the cross-compiler the path to its default sysroot, I see this: $ cd /opt/poky/1.3/sysroots/x86_64-pokysdk-linux $ cd usr/bin/armv7a-vfp-neon-poky-linux-gnueabi $ ./arm-poky-linux-gnueabi-gcc -print-sysroot /opt/poky/1.3/sysroots/armv7a-vfp-neon-poky-linux-gnueabi There is no such directory. That is, the default sysroot for the SDK doesn't exist. Now, if I go back and look in tmp/work, I realize that I see *both* of these: dm8148_mpu-poky-linux-gnueabi armv7a-vfp-neon-poky-linux-gnueabi There are a number of work directories under both. It seems to me there are these possibilities: 1) There are at least two different (and disagreeing) methods to compute the architecture "tuple," and different pieces of the system are choosing different methods. These different methods usually agree, but sometimes they don't. Thus, when they *do* agree, it's "luck." 2) These strings *should* agree, but something is missing from our machine definition that causes them to disagree (we weren't using our own machine definition until recently). In that case, the machine definition code should change such that it's not *possible* for these strings to disagree. Also, I'd like to know what we missed, so we can fix it. 3) These strings, though similar, actually *mean* different things and are *both* correct. The only problem is that the build process for the tool chain chooses the wrong one when defining the default sysroot path. In any case, I can fix the immediate problem with a symbolic link, but that's not a long-term solution. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Inconsistency in the SDK
On Jan 23, 2013, at 10:21 AM, Khem Raj mailto:raj.k...@gmail.com>> wrote: Did you source the env script before doing all that ? Thank you for your question, but it doesn't apply. All of this happens *before* I even tried to build anything. The fundamental problem is that the SDK installation script puts the native sysroot in one directory, but the tool chain believes the default location for the native sysroot is in a *different* directory that doesn't exist. On Wednesday, January 23, 2013, Patrick Turley mailto:patricktur...@gamestop.com>> wrote: > Here's our machine in local.conf: > > MACHINE = "dm8148-mpu" > > Naturally, then, we see a directly like this under tmp/work: > > dm8148_mpu-poky-linux-gnueabi > > Also, under tmp/sysroots, we see these two: > > dm8148-mpu > dm8148-mpu-tcbootstrap > > Finally, when I install the SDK, I see the following under sysroots: > > dm8148_mpu-poky-linux-gnueabi > x86_64-pokysdk-linux > > However, if I ask the cross-compiler the path to its default sysroot, I see > this: > > $ cd /opt/poky/1.3/sysroots/x86_64-pokysdk-linux > $ cd usr/bin/armv7a-vfp-neon-poky-linux-gnueabi > $ ./arm-poky-linux-gnueabi-gcc -print-sysroot > /opt/poky/1.3/sysroots/armv7a-vfp-neon-poky-linux-gnueabi > > There is no such directory. That is, the default sysroot for the SDK doesn't > exist. > > Now, if I go back and look in tmp/work, I realize that I see *both* of these: > > dm8148_mpu-poky-linux-gnueabi > armv7a-vfp-neon-poky-linux-gnueabi > > There are a number of work directories under both. > > It seems to me there are these possibilities: > > > 1) There are at least two different (and disagreeing) methods to compute the > architecture "tuple," and different pieces of the system are choosing > different methods. These different methods usually agree, but sometimes they > don't. Thus, when they *do* agree, it's "luck." > > > 2) These strings *should* agree, but something is missing from our machine > definition that causes them to disagree (we weren't using our own machine > definition until recently). In that case, the machine definition code should > change such that it's not *possible* for these strings to disagree. Also, I'd > like to know what we missed, so we can fix it. > > > 3) These strings, though similar, actually *mean* different things and are > *both* correct. The only problem is that the build process for the tool chain > chooses the wrong one when defining the default sysroot path. > > > In any case, I can fix the immediate problem with a symbolic link, but that's > not a long-term solution. > > ___ > yocto mailing list > yocto@yoctoproject.org<mailto:yocto@yoctoproject.org> > https://lists.yoctoproject.org/listinfo/yocto > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Inconsistency in the SDK
On Jan 23, 2013, at 10:19 AM, "Zhang, Jessica" wrote: > Please file a bug at bugzilla.yoctoproject.org Done: https://bugzilla.yoctoproject.org/show_bug.cgi?id=3784 Thank you. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build external module against Yocto kernel
On Jan 31, 2013, at 10:50 PM, Bruce Ashfield wrote: > On 13-01-23 10:17 AM, Patrick Turley wrote: >> >> On Jan 23, 2013, at 7:48 AM, Bruce Ashfield >> wrote: >>> On 13-01-23 12:34 AM, Patrick Turley wrote: >>>> >>>> On Jan 22, 2013, at 11:17 PM, Bruce Ashfield >>>> wrote: >>>> >>>>> On 13-01-23 12:14 AM, Patrick Turley wrote: >>>>>> On Jan 22, 2013, at 10:43 PM, Bruce >>>>>> Ashfield 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= (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= > 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
[yocto] The BitBake equivalent of "Hello, World!"
I'll start with my question (so you can decide whether you care to read
the rest):
What is the BitBake equivalent of "Hello, World!?"
Specifically, what is the minimum project structure that
correctly describes a single layer and a single recipe?
--
I'm trying to understand Yocto and BitBake thoroughly. As a start, I tried
to construct a "minimal" BitBake project, with no Yocto content.
I began by running BitBake in an empty directory and fixing each error in
turn. Eventually, I was able run BitBake without errors -- even though it
didn't actually *do* anything (which was fine).
After that, I created a single layer, and that worked fine.
Most recently, I tried to create a single recipe within my one layer. I'm
having problems I don't know how to solve.
At the bottom of this message, I show the full structure of my tree and
the contents of all the files. Since the project is "minimal," there isn't
much to show.
>From within the "build" directory of my project, I ran BitBake like this:
$ ../BitBake/bin/bitbake
Nothing to do. Use 'bitbake world' to build everything,
or run 'bitbake --help' for usage information.
That's what I expected. Then, I tried to examine the layers:
$ ../BitBake/bin/bitbake-layers show-layers
layerpathpriority
=
LayerA /home/pturley/Workspace/woohoo/LayerA 0
That's also what I expected. Things went wrong when I tried to examine the
recipes:
$ ../BitBake/bin/bitbake-layers show-recipes
Parsing recipes..$
That's wrong. I expected something like this:
Parsing recipes..done.
=== Available recipes: ===
a:
LayerA 1
At first, "base.bbclass" was empty so, on a hunch, I added this:
do_hello() {
echo Hello
}
addtask hello
That changed the output to this:
$ ../BitBake/bin/bitbake-layers show-recipes
Parsing recipes..done.
=== Available recipes: ===
a:
?1
This is still wrong, but better (though I can't explain why).
At this point I thought it best to look for experts. I don't need
hand-holding - but I *do* need substantive, accurate hints. If you have
any, I'd be grateful.
--
Here is the tree of files in my "minimal" project, along with the contents
of those file:
/home/pturley/Workspace/woohoo
|
+-- build
| |
| +-- classes
| | |
| | +-- base.bbclass
| |
| | +---
| | | do_hello() {
| | | echo Hello
| | | }
| | |
| | | addtask hello
| | +---
| |
| +-- conf
| |
| +-- bblayers.conf
| |
| | +---
| | | BBLAYERS ?= " \
| | | /home/pturley/Workspace/woohoo/LayerA \
| | | "
| | +---
| |
| +-- bitbake.conf
|
| +---
| | CACHE = "${TOPDIR}/cache"
| +---
|
+-- LayerA
| |
| +-- a.bb
| |
| | +---
| | | PN = 'a'
| | | PV = '1'
| | +---
| |
| +-- conf
| |
| +-- layer.conf
|
| +---
| | BBPATH .= ":${LAYERDIR}"
| | BBFILES += "${LAYERDIR}/*.bb"
| +---
|
+-- BitBake ...
The BitBake directory origin is:
http://git.openembedded.org/bitbake/
I have the 1.15.2 tag checked out, which is what
Yocto denzil uses.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] The BitBake equivalent of "Hello, World!"
In my previous message, some of the indentation in the representation of
my file tree was wrong (because we're using Outlook, which destroy all
indentation when you paste it into an e-mail message). The errors are
small, but I want to avoid annoying anyone who might think I don't even
have the file tree constructed correctly.
The following is accurate:
>/home/pturley/Workspace/woohoo
>|
>+-- build
>| |
>| +-- classes
>| | |
>| | +-- base.bbclass
>| |
>| | +---
>| | | do_hello() {
>| | | echo Hello
>| | | }
>| | |
>| | | addtask hello
>| | +---
>| |
>| +-- conf
>| |
>| +-- bblayers.conf
>| |
>| | +---
>| | | BBLAYERS ?= " \
>| | | /home/pturley/Workspace/woohoo/LayerA \
>| | | "
>| | +---
>| |
>| +-- bitbake.conf
>|
>| +---
>| | CACHE = "${TOPDIR}/cache"
>| +---
>|
>+-- LayerA
>| |
>| +-- a.bb
>| |
>| | +---
>| | | PN = 'a'
>| | | PV = '1'
>| | +---
>| |
>| +-- conf
>| |
>| +-- layer.conf
>|
>| +---
>| | BBPATH .= ":${LAYERDIR}"
>| | BBFILES += "${LAYERDIR}/*.bb"
>| +---
>|
>+-- BitBake ...
>
>The BitBake directory origin is:
>
>http://git.openembedded.org/bitbake/
>
>I have the 1.15.2 tag checked out, which is what
>Yocto denzil uses.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] The BitBake equivalent of "Hello, World!"
That is excellent news. I very much look forward to seeing that.
On Oct 3, 2012, at 6:03 PM, Rudolf Streif
mailto:rudolf.str...@linux.com>>
wrote:
Hi Patrick,
I think I understand what you are looking for. I created this Bitbake Hello
World for a training class. It just uses 'raw' Bitbake and a very basic recipe
to build the Nano editor (including download from the project site).
You need to have a couple of things in place to make this work. I got to run
but I will get back to it and post it.
:rjs
On Wed, Oct 3, 2012 at 3:56 PM, Patrick Turley
mailto:patricktur...@gamestop.com>> wrote:
In my previous message, some of the indentation in the representation of
my file tree was wrong (because we're using Outlook, which destroy all
indentation when you paste it into an e-mail message). The errors are
small, but I want to avoid annoying anyone who might think I don't even
have the file tree constructed correctly.
The following is accurate:
>/home/pturley/Workspace/woohoo
>|
>+-- build
>| |
>| +-- classes
>| | |
>| | +-- base.bbclass
>| |
>| | +---
>| | | do_hello() {
>| | | echo Hello
>| | | }
>| | |
>| | | addtask hello
>| | +---
>| |
>| +-- conf
>| |
>| +-- bblayers.conf
>| |
>| | +---
>| | | BBLAYERS ?= " \
>| | | /home/pturley/Workspace/woohoo/LayerA \
>| | | "
>| | +---
>| |
>| +-- bitbake.conf
>|
>| +---
>| | CACHE = "${TOPDIR}/cache"
>| +---
>|
>+-- LayerA
>| |
>| +-- a.bb<http://a.bb/>
>| |
>| | +---
>| | | PN = 'a'
>| | | PV = '1'
>| | +---
>| |
>| +-- conf
>| |
>| +-- layer.conf
>|
>| +---
>| | BBPATH .= ":${LAYERDIR}"
>| | BBFILES += "${LAYERDIR}/*.bb"
>| +---
>|
>+-- BitBake ...
>
>The BitBake directory origin is:
>
>http://git.openembedded.org/bitbake/
>
>I have the 1.15.2 tag checked out, which is what
>Yocto denzil uses.
___
yocto mailing list
yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] The BitBake equivalent of "Hello, World!"
*Very* helpful stuff.
I have re-created the tree you described, and everything seems to work. In
particular, bitbake-layers seems happy. I tried executing it against BitBake
1.12.0 and it succeeded. FYI, it failed against the current BitBake master,
which is 1.16.0.
I have some additional questions below. You've already been so helpful that
I'm reluctant to impose … but I'm going to try anyway :)
On Oct 4, 2012, at 1:58 PM, Rudolf Streif
mailto:rudolf.str...@linux.com>> wrote:
My Bitbake "Hello World" is a little more than a basic "Hello World".
Indeed it is. One of my first tasks will be to *remove* as much as possible
from this until the only thing it does is print out "Hello, World!" I'll be
happy to share my results if anyone is interested.
Bitbake will require a base.bbclass file somewhere in a classes subdirectory of
BBPATH. I used the base.bbclass file from the Bitbake download. As a minimum it
should contain a do_build task. That's the target that Bitbake invokes by
default if you do not use the -c option explicitly.
…
addtask build
do_build[dirs] = "${TOPDIR}"
do_build[nostamp] = "1"
python base_do_build () {
bb.note("The included, default BB base.bbclass does not define a useful
default task.")
bb.note("Try running the 'listtasks' task against a .bb to see what
tasks are defined.")
}
If I understand correctly, the name of the task is "build", and the name of the
Python function that implements it is "do_build()". So, it appears BitBake
prefixes all task names with "do_" to derive the name of the function that
implements the task. Have I got that right?
The "build" task is *required*, and it's the *only* one that's required?
I've been looking around in the BitBake source code a lot, so I'm *somewhat*
familiar with it. I tried to find the "hard" reference to "do_build" you
described, but I couldn't. Can you give me a hint?
Finally a recipe to build the Nano editor:
DESCRIPTION = "Recipe to build the 'nano' editor"
PN = "nano"
PV = "2.2.6"
SRC_URI = "http://www.nano-editor.org/dist/v2.2/nano-2.2.6.tar.gz";
python do_fetch() {
bb.note("Downloading source tarball from ${SRC_URI} ...")
src_uri = (bb.data.getVar('SRC_URI', d, True) or "").split()
if len(src_uri) == 0:
bb.fatal("Empty URI")
try:
bb.fetch.init(src_uri, d)
bb.fetch.go(d)
except FetchError:
bb.fatal("Could not fetch source tarball.")
bb.note("Download successful.")
}
addtask fetch before do_build
I see here that you're creating the recipe-specific "do_fetch()" function,
which seems intended to "override" the default "do_fetch()" provided by the
base class. This prompts some questions:
1) Must a "task function" be a Python function? Or will a bash function do?
2) Is it absolutely necessary to follow a recipe-specific task function with an
"addtask"? Based on experience from "real" object-oriented languages, a naive
observer (like me) would guess the simple presence of "do_fetch()" in the
recipe is all that's necessary. Or is it the "addtask" that actually "slots"
the new function in?
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] The BitBake equivalent of "Hello, World!"
And one final question: Have I been putting this on the wrong mailing list? I just discovered the mailing lists at OpenEmbedded, specifically: bitbake-de...@lists.openembedded.org Apologies if I've been bothering the wrong people. On Oct 4, 2012, at 7:47 PM, Patrick Turley wrote: > *Very* helpful stuff. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] The BitBake equivalent of "Hello, World!"
I am continuing my work on creating a "Hello, World!" BitBake project. Because
of the excellent help I got before, things have gone reasonably well, but I'm
again running into something I don't know how to fix.
As before, the entire contents of my very small project appear at the end of
this message. Here's what works fine:
$ ../BitBake/bin/bitbake-layers show-layers
Parsing recipes..done.
layer pathpriority
==
LayerA/home/pturley/Workspace/Hello/LayerA1
$ ../BitBake/bin/bitbake-layers show-recipes
Parsing recipes..done.
=== Available recipes: ===
a:
LayerA 1
When I tried this:
../BitBake/bin/bitbake -c listtasks a
I got a Python stack trace that ended here:
File "../BitBake/lib/bb/runqueue.py", line 902, in
RunQueue.check_stamp_task(task=0, taskname='do_listtasks', recurse=False):
# If the stamp is missing its not current
>if not os.access(stampfile, os.F_OK):
logger.debug(2, "Stampfile %s not available", stampfile)
TypeError: coercing to Unicode: need string or buffer, NoneType found
This code isn't expecting the "stampfile" variable to be "None" (which it is),
so it freaks out. I made a very simple fix to get past the problem:
if not stampfile or not os.access(stampfile, os.F_OK):
That made a dramatic difference, and enabled me to get this far:
$ ../BitBake/bin/bitbake -c listtasks a
Loading cache: 100%
|###| ETA: 00:00:00
Loaded 2 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing RunQueue Tasks
NOTE: Running task 1 of 1 (ID: 0,
/home/pturley/Workspace/Hello/LayerA/a.bb, do_listtasks)
ERROR: T variable not set, unable to build
ERROR: Task 0 (/home/pturley/Workspace/Hello/LayerA/a.bb, do_listtasks)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun
and 1 failed.
Summary: 1 task failed:
/home/pturley/Workspace/Hello/LayerA/a.bb, do_listtasks
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
$ ../BitBake/bin/bitbake a
Loading cache: 100%
|###| ETA: 00:00:00
Loaded 2 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing RunQueue Tasks
NOTE: Running task 1 of 1 (ID: 0,
/home/pturley/Workspace/Hello/LayerA/a.bb, do_build)
ERROR: T variable not set, unable to build
ERROR: Task 0 (/home/pturley/Workspace/Hello/LayerA/a.bb, do_build) failed
with exit code '1'
NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun
and 1 failed.
Summary: 1 task failed:
/home/pturley/Workspace/Hello/LayerA/a.bb, do_build
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
As you can see, BitBake is expecting the "T" variable to be set. I don't think
I've ever seen this variable -- so I don't know what it's for or what I should
change.
Can anyone offer a hint?
├── build
│ │
│ ├── classes
│ │ │
│ │ └── base.bbclass
│ │
│ │ +---
│ │ | addtask listtasks
│ │ |
│ │ | do_listtasks[nostamp] = "1"
│ │ |
│ │ | python do_listtasks() {
│ │ | import sys
│ │ | # emit variables and shell functions
│ │ | #bb.data.emit_env(sys.__stdout__, d)
│ │ | # emit the metadata which isnt valid shell
│ │ | for e in d.keys():
│ │ | if d.getVarFlag(e, 'task'):
│ │ | bb.plain("%s" % e)
│ │ | }
│ │ |
│ │ | addtask build
│ │ |
│ │ | do_build() {
│ │ | echo "Hello"
│ │ | }
│ │ +---
│ │
│ └── conf
│ │
│ ├── bblayers.conf
│ │
│ │ +---
│ │ | BBLAYERS ?= " \
│ │ |/home/pturley/Workspace/Hello/LayerA \
│ │ |"
│ │ +---
│ │
│ └── bitbake.conf
│
│ +---
│ | CACHE = "${TOPDIR}/cache"
│ +---
│
├── LayerA
│ │
│ ├── a.bb
│ │
│ │ +---
│ │ | DESCRIPTION = "Layer A Main Recipe"
│ │ | PN = 'a'
│ │ | PV = '1'
│ │ +---
Re: [yocto] The BitBake equivalent of "Hello, World!"
Success. The file tree depicted at the bottom of this mail is nearly the
smallest, valid BitBake project that prints "Hello, World!" Here's the output:
$ ../BitBake/bin/bitbake a
Parsing recipes: 100%
|#| Time: 00:00:00
Parsing of 1 .bb files complete (0 cached, 1 parsed). 1 targets, 0 skipped,
0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing RunQueue Tasks
NOTE: Running task 1 of 1 (ID: 0,
/home/pturley/Workspace/Hello/LayerA/a.bb, do_build)
NOTE: package None: task do_build: Started
Hello, World!
NOTE: package None: task do_build: Succeeded
NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun
and all succeeded.
A few things to note:
1) This is not the *smallest* such BitBake project. For example, the
"DESCRIPTION" and "PV" variables need not be assigned in "a.bb". I set those
variables because I wanted "show-layers" and "show-recipes" to display
reasonable information.
2) Some of the variables set in "bitbake.conf" have "simplified" values. For
example, you would *not* want to use these values if there were multiple
recipes and you had to disambiguate the output from each of them.
3) On the other hand, *all* the variable assignments in "bitbake.conf" are
*essential* to BitBake itself. If you remove any one of those assignments,
BitBake will either declare an error or die (usually because some internal
variable is set to "None" and the BitBake code can't handle it).
├── build
│ │
│ ├── classes
│ │ │
│ │ └── base.bbclass
│ │
│ │ +---
│ │ | addtask build
│ │ +---
│ │
│ └── conf
│ │
│ ├── bblayers.conf
│ │
│ │ +---
│ │ | BBLAYERS ?= " \
│ │ |/home/pturley/Workspace/Hello/LayerA \
│ │ |"
│ │ +---
│ │
│ └── bitbake.conf
│
│ +---
│ | TMPDIR = "${TOPDIR}/tmp"
│ | CACHE = "${TMPDIR}/cache"
│ | STAMP = "${TMPDIR}/stamps"
│ | T = "${TMPDIR}/work"
│ | B = "${TMPDIR}"
│ +---
│
├── LayerA
│ │
│ ├── a.bb
│ │
│ │ +---
│ │ | DESCRIPTION = "Layer A Recipe"
│ │ | PN = 'a'
│ │ | PV = '1'
│ │ |
│ │ | python do_build() {
│ │ | bb.plain("Hello, World!");
│ │ | }
│ │ +---
│ │
│ └── conf
│ │
│ └── layer.conf
│
│ +---
│ | BBPATH .= ":${LAYERDIR}"
│ |
│ | BBFILES += "${LAYERDIR}/*.bb"
│ |
│ | BBFILE_COLLECTIONS += "A"
│ | BBFILE_PATTERN_A := "^${LAYERDIR}/"
│ +---
│
└── BitBake
The BitBake directory origin is:
http://git.openembedded.org/bitbake/
I have the 1.15.2 tag checked out, which is what
Yocto denzil uses.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] The BitBake equivalent of "Hello, World!"
That's a perfectly reasonable suggestion, and a good excuse for me to open a
github account and learn how to use it :)
On Oct 9, 2012, at 5:56 PM, McClintock Matthew-B29882
wrote:
> On Tue, Oct 9, 2012 at 5:31 PM, Patrick Turley
> wrote:
>> Success. The file tree depicted at the bottom of this mail is nearly the
>> smallest, valid BitBake project that prints "Hello, World!" Here's the
>> output:
>
> Perhaps you could push this to github somewhere as an example?
>
> -M
>
>>
>>
>>$ ../BitBake/bin/bitbake a
>>Parsing recipes: 100%
>> |#| Time:
>> 00:00:00
>>Parsing of 1 .bb files complete (0 cached, 1 parsed). 1 targets, 0
>> skipped, 0 masked, 0 errors.
>>NOTE: Resolving any missing task queue dependencies
>>NOTE: Preparing runqueue
>>NOTE: Executing RunQueue Tasks
>>NOTE: Running task 1 of 1 (ID: 0,
>> /home/pturley/Workspace/Hello/LayerA/a.bb, do_build)
>>NOTE: package None: task do_build: Started
>>Hello, World!
>>NOTE: package None: task do_build: Succeeded
>>NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be
>> rerun and all succeeded.
>>
>>
>> A few things to note:
>>
>> 1) This is not the *smallest* such BitBake project. For example, the
>> "DESCRIPTION" and "PV" variables need not be assigned in "a.bb". I set those
>> variables because I wanted "show-layers" and "show-recipes" to display
>> reasonable information.
>>
>> 2) Some of the variables set in "bitbake.conf" have "simplified" values. For
>> example, you would *not* want to use these values if there were multiple
>> recipes and you had to disambiguate the output from each of them.
>>
>> 3) On the other hand, *all* the variable assignments in "bitbake.conf" are
>> *essential* to BitBake itself. If you remove any one of those assignments,
>> BitBake will either declare an error or die (usually because some internal
>> variable is set to "None" and the BitBake code can't handle it).
>>
>>
>>
>>
>>
>> ├── build
>> │ │
>> │ ├── classes
>> │ │ │
>> │ │ └── base.bbclass
>> │ │
>> │ │ +---
>> │ │ | addtask build
>> │ │ +---
>> │ │
>> │ └── conf
>> │ │
>> │ ├── bblayers.conf
>> │ │
>> │ │ +---
>> │ │ | BBLAYERS ?= " \
>> │ │ |/home/pturley/Workspace/Hello/LayerA \
>> │ │ |"
>> │ │ +---
>> │ │
>> │ └── bitbake.conf
>> │
>> │ +---
>> │ | TMPDIR = "${TOPDIR}/tmp"
>> │ | CACHE = "${TMPDIR}/cache"
>> │ | STAMP = "${TMPDIR}/stamps"
>> │ | T = "${TMPDIR}/work"
>> │ | B = "${TMPDIR}"
>> │ +---
>> │
>> ├── LayerA
>> │ │
>> │ ├── a.bb
>> │ │
>> │ │ +---
>> │ │ | DESCRIPTION = "Layer A Recipe"
>> │ │ | PN = 'a'
>> │ │ | PV = '1'
>> │ │ |
>> │ │ | python do_build() {
>> │ │ | bb.plain("Hello, World!");
>> │ │ | }
>> │ │ +---
>> │ │
>> │ └── conf
>> │ │
>> │ └── layer.conf
>> │
>> │ +---
>> │ | BBPATH .= ":${LAYERDIR}"
>> │ |
>> │ | BBFILES += "${LAYERDIR}/*.bb"
>> │ |
>> │ | BBFILE_COLLECTIONS += "A"
>> │ | BBFILE_PATTERN_A := "^${LAYERDIR}/"
>> │ +---
>> │
>> └── BitBake
>>
>> The BitBake directory origin is:
>>
>> http://git.openembedded.org/bitbake/
>>
>> I have the 1.15.2 tag checked out, which is what
>> Yocto denzil uses.
>>
>>
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] how does one use a prebuilt toolchain from the toolchain/ directory?
I just read your posting of 26 June on the Yocto mailing list: https://lists.yoctoproject.org/pipermail/yocto/2012-June/009714.html I didn't see any responses. Did you get any help with this issue? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] The BitBake equivalent of "Hello, World!"
https://github.com/pturley0/bitbake-hello-world On Oct 9, 2012, at 5:56 PM, McClintock Matthew-B29882 wrote: > On Tue, Oct 9, 2012 at 5:31 PM, Patrick Turley > wrote: >> Success. The file tree depicted at the bottom of this mail is nearly the >> smallest, valid BitBake project that prints "Hello, World!" Here's the >> output: > > Perhaps you could push this to github somewhere as an example? > > -M ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Disguising Yocto sysroot as Code Sourcery tool chain
We have a piece of software that is normally built with a Code Sourcery tool chain. We want to build it with a Yocto-produced tool chain instead. The shortest (though admittedly "hackiest") path to success may be to create a file tree that *looks* like a Code Sourcery tool chain, but is actually populated with executables and other files from a Yocto sysroot. I thought it worthwhile to ask this mailing list and see if anyone else has done anything similar (Google turned up nothing). If you have anything to share about your experiences, I would be very grateful. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
