**** BEGIN LOGGING AT Thu Feb 12 02:59:58 2015 Feb 12 03:54:37 which git tree holds the yocto kernel for edison? i've found i can manually apply upstream_to_edison.patch from the yocto GPL sources for edison, but haven't found a branch/tag in that has those changes via http://git.yoctoproject.org/git/linux-yocto-3.10 Feb 12 03:56:32 (was hoping for a patch series vs. a monolithic "enable edison" patch bomb) Feb 12 06:08:29 hi..suppose if I want to configure a package to install to /usr for example, what variable should I set to --prefix? ${D}? Feb 12 06:12:29 chankit: depends on the package, with an autotools pacakge the configure --prefix=/usr and then the make DESTDIR=${D} install will handle the cross install Feb 12 06:15:12 chankit: actually if its an autotools package, you should just use the autotools class as the default ${prefix} is "/usr" and it will handle the rest for you Feb 12 06:24:21 nrossi: I'm using cmake. I checked cmake.bbclass and it seems that it uses ${prefix} as well... Feb 12 06:24:38 will also make note of make DESTDIR=${D} install Feb 12 06:24:41 thanks :-) Feb 12 06:26:02 BTW why make DESTDIR=${D} install instead of simply make install? Feb 12 06:26:31 since the compilation has been already configured to install to ${prefix} Feb 12 06:26:38 chankit: so that it installs into the ${D} directory which is down under the tmp/ build directory Feb 12 06:27:01 chankit: without passing that it will try to install it into your hosts '/usr' directory Feb 12 06:27:37 chankit: btw cmake.bbclass relies on autotools.bbclass for the do_install step, so they both do the make DESTDIR=${D} install Feb 12 06:29:15 nrossi: ok..I do get files were installed but not shipped problem. Must I specify FILES-${PN} variable or is there a more elegant way? Feb 12 06:31:24 chankit: there are some defaults rules for FILES_${PN}, however you will need to populate that variable for more specific things Feb 12 06:34:20 nrossi: what are the default rules? Is there another bbclass that I can reference? Feb 12 06:36:32 chankit: the defaults are set in bitbake.conf, see https://github.com/openembedded/openembedded-core/blob/master/meta/conf/bitbake.conf#L268 Feb 12 06:37:04 chankit: you should no need to explicitly include them, just append the ones you need that are not covered by the defaults Feb 12 06:37:10 not* Feb 12 06:40:59 nrossi: the weird thing is a lot if not all files are caught in the installed but not shipped error Feb 12 06:41:50 chankit: got an example? you can use wildcards in the FILES_${PN} variable, so if needed you can do something like FILES_${PN} += "/usr/bin/packagefoo/*" Feb 12 06:43:11 a quick example would be /usr/lib Feb 12 06:43:11 /usr/lib/libLLVMX86AsmParser.a Feb 12 06:44:13 but FILES_${PN} includes ${libexecdir} Feb 12 06:44:28 according to bitbake.conf Feb 12 06:44:30 chankit: ahh thats a static lib, you will want to add a ${PN}-staticdev package for that Feb 12 06:44:47 chankit: in your recipes do something like: Feb 12 06:44:57 chankit: PACKAGES += "${PN}-staticdev" Feb 12 06:46:51 chankit: there are pre-defined FILES values for ${PN}-staticdev, so you just need to declare that you have a staticdev package and it should pick up the files Feb 12 06:50:35 nrossi: are ${PN}-staticdev and ${PN}-dev exclusive to each other? Feb 12 06:51:19 now I got packagename-staticdev is listed in PACKAGES multiple times, this leads to packaging errors. Feb 12 06:54:18 chankit: oh sorry my bad, thats actually a default value Feb 12 06:55:06 I did bitbake -e and got PACKAGES="llvm-dbg llvm-staticdev llvm-dev llvm-doc llvm-locale llvm" Feb 12 06:55:33 that's quite weird Feb 12 06:55:47 chankit: ok thats what you want. Just check that FILES_${PN} has the values you expect Feb 12 06:56:03 chankit: and same for FILES_${PN}-staticdev Feb 12 06:59:22 this could have something to do with the fact that I have multilib enabled Feb 12 07:00:38 chankit: hmmm maybe, but you would get most likely get a error/warning different to not shipped, you are building the non-multilibed version yes? Feb 12 07:01:47 actually I'm building multilib yocto Feb 12 07:02:15 chankit: yep but your building llvm not llvm-lib32 or something right? Feb 12 07:02:37 nope..llvm 64 bit Feb 12 07:02:51 *yes Feb 12 07:03:50 chankit: if possible, would you be able to dump the output from 'bitbake llvm -e' to a gist/pastbin? Feb 12 07:09:06 nrossi: you mean bitbake -e llvm? Feb 12 07:09:19 bitbake llvm -e is really big Feb 12 07:17:15 Hi Feb 12 07:22:42 chankit: -e llvm or llvm -e are the same no? Feb 12 07:23:10 hi Frank Feb 12 07:25:32 chankit: also it shouldn't be too big, at most 1MB, things like gist.github.com allow you to add files ;) Feb 12 07:36:12 chankit: btw, not sure if you were aware or not, but there are llvm recipes in the meta-oe, https://github.com/openembedded/meta-openembedded/tree/master/meta-oe/recipes-core/llvm Feb 12 08:25:43 nrossi: sorry for the late reply...it seems that bitbake -e llvm and bitbake llvm -e are different Feb 12 08:26:00 here's the output of bitbake llvm -e https://gist.github.com/anonymous/607ab2507c2cfa269134 Feb 12 08:26:38 I actually tried the recipe that you showed earlier but I got the roughly same issue of installed but not shipped error Feb 12 08:27:05 chankit: ok, lets have a look Feb 12 08:28:21 chankit: ah thats interesting, does llvm treat /usr/lib and /usr/lib64 differently? Feb 12 08:29:15 nrossi: I'm not sure..btw how do you read such a big file? Feb 12 08:29:22 chankit: ah yep, the multilib stuff is causing the issue. baselib="lib64" Feb 12 08:29:34 chankit: grep or Ctrl+F Feb 12 08:29:48 what do you grep? Feb 12 08:30:19 chankit: various variables, for example grep -C 10 -in "baselib=" Feb 12 08:30:54 nrossi: interesting.... Feb 12 08:30:54 chankit: works better when using less/vim or in a browser using find Feb 12 08:31:09 nrossi: lemme try disabling multilib and see what happens... Feb 12 08:31:31 chankit: so i think you will find that llvm is not honouring or not being told that the lib dir is different Feb 12 08:32:27 nrossi: probably...I'm ashamed to confess that I don't know much of both yocto and llvm Feb 12 08:32:34 but I'm happy to learn Feb 12 08:32:47 chankit: yer i would say llvm is not handling the configure args, e.g. --libexecdir=/usr/lib64/llvm Feb 12 08:33:31 could cmake.bbclass be the culprit Feb 12 08:33:35 lemme check cmake.bbclass Feb 12 08:33:47 chankit: most effective solution would be to add some do_install_prepend steps to move /usr/lib to /usr/lib64 if ${baselib} is not lib sort of thing Feb 12 08:34:06 chankit: no i imagine llvm just doesn't use the --libdir/--libexecdir args Feb 12 08:34:42 nrossi: you're right..cmake.bbclass uses prefix value so if prefix is set right then it should be sailing Feb 12 08:35:44 chankit: looking at some random llvm repo, it appears that the configure script just specifies ${exec_prefix}/lib for libdir Feb 12 08:35:47 chankit: https://github.com/llvm-mirror/llvm/blob/master/configure#L859 Feb 12 08:37:49 chankit: i think all you will need to do is add this somewhere in your recipe: Feb 12 08:37:50 do_install_append() { Feb 12 08:37:50 if [ "${baselib}" != "lib" ]; then Feb 12 08:37:50 mv ${D}/usr/lib ${D}/usr/${baselib} Feb 12 08:37:50 fi Feb 12 08:38:03 } Feb 12 08:38:07 nrossi: yeah it looks like I need to specify LLVM_LIBDIR_SUFFIX Feb 12 08:38:08 http://www.llvm.org/docs/CMake.html#id9 Feb 12 08:39:37 chankit: that looks better, yep, you can even specify something like that from your local.conf Feb 12 08:39:50 how? Feb 12 08:40:10 export LLVM_LIBDIR_SUFFIX_pn-llvm = "64" Feb 12 08:41:16 chankit: but i would recommend making the change to the llvm.inc file in meta-oe, and submitting a patch. That way someone else doesn't hit the same issue you have ;) Feb 12 08:41:44 nrossi: so many solutions lol...now I have to see if disabling the multilib does solve the issue... Feb 12 08:42:19 nrossi: if you don't mind me asking..how do you learn stuffs in yocto? Feb 12 08:42:44 things that we talked about don't really exist in the docs Feb 12 08:43:23 chankit: been using it at work for about 2 years. Doing BSPs for Xilinx's SoC's is always a challenge ;) Feb 12 08:44:36 chankit: i guess it also helps when you push the envolpe and hit issues, you find the limitations of tools and how they break Feb 12 08:47:26 nrossi: so I assume you work with the kernel stuff as well? Feb 12 08:47:36 how do you port the patches between kernel versions? Feb 12 08:48:37 chankit: depends, what sort of patches? Feb 12 08:49:07 chankit: as in are you touching core kernel or just outling drivers? Feb 12 08:49:56 nrossi: erm...let's not be too specific here ;-) Let's say if you want to test out new kernel versions that yocto doesn't have yet. So how do you port the new kernel in yocto? Feb 12 08:52:07 chankit: hmmm sort of depends, its worth having a look at some of the recipes that are available for that sort of thing Feb 12 08:52:11 chankit: https://github.com/openembedded/openembedded-core/blob/master/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb Feb 12 08:53:02 chankit: however the linux-yocto guys are pretty quick at picking up the newer kernels, so have a look at linux-yocto-dev Feb 12 08:59:32 nrossi: so referring to the linux-yocto-custom.bb, can I simply change the kernel version? Feb 12 09:00:17 and I also checked linux-yocto-dev but I only saw zip files...so I'm not entirely sure what do I do with the zip files Feb 12 09:01:22 chankit: its a reference recipe, its got some documentation at the top of it. Feb 12 09:01:37 chankit: regarding linux-yocto-dev what do you mean by zip files? Feb 12 09:01:57 nrossi: http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-dev/ Feb 12 09:03:05 chankit: you can just use it via some local.conf settings, PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-dev" Feb 12 09:06:21 nrossi: if I set that it will always check the latest kernel from yocto repo? Feb 12 09:06:50 chankit: the latest linux-yocto-dev kernel yes Feb 12 09:11:03 nrossi: thanks a lot for the info :-) Really appreciate it Feb 12 09:11:19 will let u know the compilation results soon Feb 12 09:12:26 chankit: np, i will be heading off shortly, so if i dont reply... i will be back in approx 14 hours :) Feb 12 09:12:42 me too actually :-) Feb 12 09:13:51 nrossi: if you don't mind me asking...where are you from? Feb 12 09:14:07 chankit: Down under mate ;) Feb 12 09:14:31 nrossi: ah I see.... Feb 12 09:14:54 chankit: what about you? Feb 12 09:15:25 nrossi: malaysia..the reason I'm asking is you might have similar timezome Feb 12 09:15:41 what's your timezone? GMT+8? Feb 12 09:15:46 +10 Feb 12 09:16:07 nrossi: you should be really off now lol Feb 12 09:16:31 chankit: haha, :) Feb 12 09:17:09 i can't imagine working until 7 Feb 12 09:17:23 I used to get off at 4.30 and I really miss that Feb 12 09:18:03 chankit: i normally get in quite late, so it works better for me ;) Feb 12 09:18:33 nrossi: I see..you get the miss the rush hour huh Feb 12 09:19:16 chankit: also known as the 'parking lot' time of the day Feb 12 09:19:56 nrossi: didn't see that coming but that's a good one Feb 12 09:20:10 nrossi: but finding parking is harder since you arrive late Feb 12 09:20:54 chankit: that can be a problem also Feb 12 09:21:33 chankit: anyways i gtg, goodluck with your build, until next time. See ya! :) Feb 12 09:24:39 see ya Feb 12 09:24:48 have a good die Feb 12 09:25:46 *evening Feb 12 09:30:45 morning all Feb 12 11:13:18 hey bluelightning, what is the best resource for figuring out how to build a specific image. I'm a noob w/ yocto and am having a tought time with trying to build a xen image provided by the meta-virtualization layer. Feb 12 11:13:41 the kvm layer builds Feb 12 11:14:14 sry, kvm image provided by the meta-virtualization layer builds fine Feb 12 11:14:28 j105rob: are there any special instructions in the README for the layer? (I'm assuming there is one) Feb 12 11:15:15 in the readme of the root of the layer, there are only sections for dependencies, maintenance and the license Feb 12 11:15:50 ok, and you have all of the dependencies? Feb 12 11:15:59 I sent an email to the meta-virtualization mailing list yesterday Feb 12 11:16:05 yes, I have all the dependencies Feb 12 11:20:26 ok... well I have pretty much no experience with meta-virtualization; it's surprising that the xen image wouldn't build out of the box with the error you're receiving :/ Feb 12 11:20:54 hmm.. I guess I'll have to wait to hear back from the listserv Feb 12 11:21:00 thx! Feb 12 11:21:02 if you wanted to debug it my first suggestion would be to "git grep" for references to the item it is reporting as unbuildable Feb 12 11:21:22 and find the recipe that's supposed to be providing it Feb 12 11:21:59 j105rob: nrossi did reply to your email, I just noticed Feb 12 11:22:29 I did not get a notification of that, yet, where are you seeing that response> Feb 12 11:22:30 ? Feb 12 11:22:51 I'm subscribed to the list, it's just appeared here Feb 12 11:23:14 here's the email in the archive FWIW: https://lists.yoctoproject.org/pipermail/meta-virtualization/2015-February/000872.html Feb 12 11:23:57 thx Feb 12 12:17:33 kergoth: yes, calling libtoolize --force --copy --install in configure_prepend() works too. i'll send a patch for it. Feb 12 12:59:05 what's the correct package to depend on if you have a thing that supports qt4 mainloop integration? Feb 12 12:59:27 I've set it to qt4-x11-free for now, but that of course that's kind of limiting Feb 12 13:05:29 hi, I have a question. Anyone knows if it is possible to use OVERRIDES in a recipe containing the image name? I dont want to add machine specific but image specific overrides. Thanks! Feb 12 13:20:07 estereta: what are you trying to do? Feb 12 13:22:28 we have different images, containing different applications. One application (the hmi) needs to use different QML Feb 12 13:22:32 depending on the image Feb 12 13:23:07 the guy who is taking care of this wanted to actually have only one hmi recipe and do something like SRC_URI_append_ Feb 12 13:23:24 but all the documentation I can read/find points to this being a bad approach Feb 12 13:23:38 estereta, No, not if you need a build-time change Feb 12 13:24:14 yes, its build time. We need different config files, different QML, and whatever other stuff Feb 12 13:24:27 if you want to do it repeatably make a recipe Feb 12 13:25:07 I also think better approach is to have one hmi.inc and different hmi.bb files depending on the image right? Feb 12 13:25:15 I'd say: hmi-image1.bb and hmi-image2.bb that both shares hdmi.inc. Feb 12 13:25:29 yeah I think also Feb 12 13:25:33 thx a lot! Feb 12 13:26:17 yes thats the best image approach, the other way is to add a personaliry/config mount point Feb 12 13:29:18 what is that? Feb 12 13:36:41 Hey, I'm scratching my head on dependencies - I've got two image recipes e.g. "my-image-app.bb" & "my-image-recovery.bb" - Now these get combined into a package by a tool I have that I want to put into another recipe "my-image-firmwareload.bb". I've added a DEPENDS="my-image-app my-image-recovery" in the recipe but it doesn't generate the images under tmp/deploy which is where the other recipe picks them up from to bundle together. I get the feeling im m Feb 12 13:36:41 issing something obvious...! Feb 12 13:45:49 pev, you might need something along do_rootfs[depends] += "my-image-app:do_rootfs" in your my-image-firmwareload.bb... At least that's how I think I solved something similar quite a while ago. Feb 12 14:03:48 AndersD: Cheers, I'll give that a go! TBH I havent sussed out yet how to correctly invoke my script in there yet anyway and can't find a good example as yet. Feb 12 14:04:02 Its always the "trivial" things that seem to take longest...?! Feb 12 14:55:54 Hi. Anyone that knows if it's possible to set LAYERDEPENDS_ with for example MACHINEOVERRIDES. I wan't to set layerdepends only for specific images in a layer. Feb 12 14:58:30 wouldnt make any sense, no. layers are processed long before the machine is even set Feb 12 15:08:03 kergoth: That was what I more or less suspected. Well I guess it's too much of a "Both have the cake and eat it..". I want to solve the case when I want the early and clear error displayed by LAYERDEPENDS but for ppl using this layer and never builds the images that have separate depends it feels like waste to force them to have it to be able to build. So I guess the conclusion is that we have to continue to just have a readme that expl Feb 12 15:16:14 kergoth: sorry just got back from 3 days on road, will respond to your e-mails today re: ADE, etc. Feb 12 15:18:26 zerus_: one possibility is to have per-layer areas which are only processed when those layers exist. this mechanism is most useful to deal with appending to things that might or might not exist, but it's certainly possible to put recipes there as well. https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mel/conf/layer.conf#L5-L10 — then put your image in e.g. openembedded-layer/recipes-foo/bar/baz-image.bb and it'd only be available when Feb 12 15:18:26 meta-oe is included Feb 12 15:18:30 zerus_: really depends on the goals Feb 12 15:18:34 but worth considering Feb 12 15:18:40 challinan: np, thanks Feb 12 15:19:42 kergoth: remind me, what should I name the local.conf extension in my layer for it to be picked up? Feb 12 15:19:46 local.conf.append? Feb 12 15:20:18 challinan: yes, but we might want to take mel-specifics to our channel :) it's "conf/local.conf.append" or "conf/local.conf.append.$MACHINE" relative to the top of the layer Feb 12 15:22:34 oops! duh! need another cup of coffee ;) Feb 12 15:22:41 * bluelightning closes his ears Feb 12 15:23:19 heh Feb 12 15:23:37 well, some of that is in the public layers anyway, e.g. the hooks to append to local.conf :) Feb 12 15:26:25 I do still have that page of yours about MEL enhancements to move to the core open in a tab, with the intent of looking into what you guys have been up to :) Feb 12 15:27:01 I'll admit that it has been open since you linked to it a while back though Feb 12 15:27:05 heh, i do need to go comb through the layers again, we're behind on the submissions of staged fixes again, as is always the case right after a product release Feb 12 15:28:16 hmm, do you need to always set S for git based recipes? I see the cmake thing is trying to use the directory instead of where it actually cloned the sources... Feb 12 15:28:49 so it's trying to cmake which naturally doesn't find cmakelist.txt Feb 12 15:29:32 kergoth: I will look into the meta-mel example and see if that is possible way forward in this case, thx. Feb 12 15:29:43 np Feb 12 15:31:50 JEEBsv: somewhere in the docs... it says what the default value of S is... but it's only suitable for "normal tarballs." For everything else you have to change it. Feb 12 15:32:55 ok Feb 12 15:32:58 thanks Feb 12 15:33:18 yeah, the default thing is handle'able if you are using tarballs Feb 12 15:37:16 kind of a shame, though. since the system knows if you are using git or not :/ Feb 12 15:37:49 so you just get a lot of recipes with "S = "${WORKDIR}/git"" or so Feb 12 17:38:47 bluelightning_: do you happen to know how to build xen-image-minimal ? I'm getting errors.... Feb 12 17:39:49 bobdog555: are they either of the two errors mentioned in this thread? https://lists.yoctoproject.org/pipermail/meta-virtualization/2015-February/000871.html Feb 12 17:40:16 bluelightning: checking.... Feb 12 17:43:07 bobdog555: check handles.... that's mine.... Feb 12 17:43:20 bluelightning: bobdog555 and I work together. Feb 12 17:43:26 bluelightning: yes, for the second one, "Nothing RPROVIDES 'xen-base' ..." . I've tried fresh downloads from github (versus OE or yocto) Feb 12 17:43:53 bluelightning: yes and j105rob is a good guy most days. Feb 12 17:44:44 j105rob: ah I see :) Feb 12 17:45:02 bobdog555: I thought j105rob had addressed that one based on the thread Feb 12 17:46:15 bluelightning: he fixed the x86 part (the first bug), but neither of us has been able to solve the second one: no xen-base to be found anywhere. Feb 12 17:46:28 yes, machine in local.conf needs to be genericx86-64 Feb 12 17:47:31 the xen-base is not the problem now, the problem now is in the do_config() of the xen tools. Rules.mk error Feb 12 17:48:02 when running the seabios-dir make scrit Feb 12 17:48:12 script to fix the compiler Feb 12 17:50:16 is it possible to use icecc for building yocto on linux and osx workers. the osx worker won't be able to compile some things that require linux but the rest should work. Feb 12 17:52:16 hrm... the -native packages would have to be built for both sides ... Feb 12 17:54:44 bluelightning: j105rob is correct; I mis-spoke. And he's a good guy all the time :) Feb 12 17:55:49 bobdog555: ok, I don't have any extra info on meta-virtualization I'm afraid, it's not something I've really played with Feb 12 17:58:34 bluelightning: Thanks anyway, as always. Feb 12 18:07:45 darknighte, & Jefro1 Do we have time to talk about the content part of DevDay? Feb 12 18:09:10 halstead: read my mind. Feb 12 18:09:23 Jefro1: is trying to reach you to join a telecon Feb 12 19:01:24 Hm, do_rootfs[depends] += "my-image-app:do_rootfs" doesn't seem to work - tried adding do_deploy as well... What would trigger the dependency to re-populate the DEPLOY_IMAGE_DIR? Feb 12 19:09:49 pev: The do_rootfs task should be the thing that writes to the deploy directory Feb 12 19:10:00 Hm.... Feb 12 19:10:35 pev: You can see where it calls create_image() in do_rootfs() in meta/classes/image.bbclass Feb 12 19:11:18 Even though I've added DEPENDS="my-image-app" and do_rootfs[depends] += "my-image-app:do_rootfs" the deploy image dir doesnt even get created let alone populated?? Feb 12 19:13:58 I don't know what is in your recipe. Does my-image-firmwareload.bb, have a do_rootfs() task? Feb 12 19:15:14 If not, i.e. you aren't actually creating an image, then you don't want to use do_rootfs[depends], you need to use a task that is actually in your recipe. Feb 12 19:15:15 Nope, it just has a task to generate an image... Does it need some kind of stub task I wonder? Feb 12 19:15:30 I just have a custom task called do_mkimage... Feb 12 19:15:47 then try do_mkimage[depends Feb 12 19:16:38 rewitt: Ah, good spot! Feb 12 19:16:40 :-) Feb 12 19:16:41 Does that make sense? If no rootfs task is running for my-image-firmwareload.bb, then it doesn't matter that the task is dependent on the rootfs for the other images Feb 12 19:17:10 Yep Feb 12 19:17:16 totally Feb 12 19:17:23 I just assumed it was an implicit thing Feb 12 19:17:35 Well it is if you include image.bbclass Feb 12 19:18:11 I hope that fixes it for you Feb 12 19:19:06 rewitt: Yep, it's just ticking over now, thanks! Feb 12 19:19:20 Nice, you're welcome. Feb 12 20:46:10 hi all, I changed some properties and I am trying to build my image, however MLO and u-boot.img arent being built when I build the image. I also cleaned out the tmp directory, am I missing somethign here? Feb 12 21:32:05 Hi. Can I use a build made with yocto, for commercial use, for free? Feb 12 21:50:52 if you conform to the licenses of the packages you a distributing, yes. Feb 12 21:50:59 you are** Feb 12 21:54:06 neverpanic: okey thank you. Feb 12 21:54:49 Is it better to make in linux, than Build appliance in windows for example? or does it matter? Feb 12 21:55:50 If you're in doubt about this, please contact a laywer. I am not a qualified legal counsel and it would be unethical (and in some jurisdictions possibly illegal) to advise you on licensing issues. Feb 12 21:55:55 I do not understand this question. Feb 12 21:56:21 neverpanic: Okey I got you. Feb 12 21:58:55 neverpanic: I meant if tyhere is a disadvantage to make Yocto projects on windows with Build Apliance option, over using linux. I am just starting this, so I just want to know if it recommended to use a particullary OS Feb 12 21:59:40 you mean whether there's a difference to building it in a virtual Linux machine on Windows, or directly on Linux? Feb 12 22:00:10 Functionally, those should be the same. Performance-wise, the VM might be slower, but depending on your requirements that might not matter. Feb 12 22:00:52 neverpanic: Hmm maybe. I am downloading Yocto Project Build Appliance zip file now. Does that mean I do need a virtual linux machine anyways? Feb 12 22:01:23 From the quick start -> If you don't have a system that runs Linux and you want to give the Yocto Project a test run, you might consider using the Yocto Project Build Appliance. The Build Appliance allows you to build and boot a custom embedded Linux image with the Yocto Project using a non-Linux development system. See the Yocto Project Build Appliance for more information. Feb 12 22:02:08 neverpanic: Doh. sorry. I got it now. I am not english is my excuse Feb 12 22:02:26 virtual machine of some kind, so it does not matter Feb 12 22:02:39 The Yocto Project Build Appliance is a virtual machine Feb 12 22:02:48 neverpanic: got it Feb 12 22:24:20 connect Feb 12 22:44:28 neverpanic: actually the virtual will be slower ofcourse. Other than that its the same. Feb 12 22:55:19 when i 'bitbake my-image' and then i do a 'bitbake -c populate_sdk my-image' to generate a SDK.. the SDK includes libstdc++.so while my image does not.. Feb 12 22:55:40 my application is a c++ application.. is there a way to tell my image to include this? Feb 12 22:56:38 in my-image.bb I do have a "IMAGE_INSTALL += libstdc++" in there.. but it didn't seem to make a difference.. Feb 12 22:57:03 help or pointers to docs would be great.. my google-fu is running out trying to track down documentation.. Feb 12 23:51:11 im trying to debug a usb chip not being initialized, and when i run lsusb, I am getting the message "unable to initialize libusb: -99" Feb 13 00:52:47 What should I set default machine in conf/local.conf, to if I build for a pcDuino3? Feb 13 01:27:39 with export LIBUSB_DEBUG=3, I see the following error: libusb: error [op_init] could not find usbfs Feb 13 01:55:29 nrossi: you there? Feb 13 02:01:43 chankit: am now ;) Feb 13 02:04:15 nrossi: I have one good news and one bad news. The good news is it all goes well and llvm is well inside yocto. However, the binary generated by this compiler isn't compatible with the target platform. Surprisingly, that binary is compatible with my build machine. Feb 13 02:04:57 nrossi: actually I have been stuck with this problem(binary incompatibility) for some time now Feb 13 02:05:03 chankit: oooo that is quite an issue, so you built a llvm that runs on the target but builds for your buildhost? Feb 13 02:06:19 I did ldd on that binary on my build machine and here's the result http://pastebin.com/pjLYe3nm Feb 13 02:06:53 note that /lib64 is there which suggests that there is still problem with the cross compiling thingy Feb 13 02:07:24 nrossi: I did that although that's not what I want to do Feb 13 02:07:47 chankit: ok, but are you still using the multilib configuration? Feb 13 02:07:54 Nope Feb 13 02:08:18 chankit: are you using your own llvm recipe or have you gone to the one in meta-oe? Feb 13 02:08:30 Using multilib avoids the binary incompatibility problem since they are binary compatible with each other Feb 13 02:08:36 my own Feb 13 02:08:56 coz the one in meta-oe isn't working for me :-( Feb 13 02:10:52 chankit: have you written any complex recipes like this before? if not i might be a good idea to stick with the meta-oe version. Feb 13 02:13:58 chankit: hmmm llvm looks like it might build differently than other applications, the one thats in meta-oe looks like it is a native 'host-only' build... not sure what that means. Unfortunately my knowledge of llvm is very limited Feb 13 02:15:56 chankit: my understanding is that you want to build an llvm that runs on your target to build for your target, correct? Feb 13 02:16:09 nrossi: yes Feb 13 02:20:50 chankit: http://llvm.org/docs/HowToCrossCompileLLVM.html this page looks like it might be very helpful Feb 13 02:20:51 chankit: it appears you are going to want to set some of those CMake options in order to specify the target Feb 13 02:29:10 nrossi: doing that as we speak...I'm also in LLVM IRC so let's hope something good comes out from that Feb 13 02:30:03 chankit: hmmm just looking at the recipe in meta-oe, i can see what needs to be changed to get it to work. Firstly the "--enable-targets=host-only" -> "--enable-targets=all" Feb 13 02:30:36 chankit: i will have a play with it here, see what i get going **** ENDING LOGGING AT Fri Feb 13 02:59:58 2015