**** BEGIN LOGGING AT Mon May 26 03:00:00 2014 May 26 07:12:40 good morning May 26 07:17:52 morning mckoan May 26 08:34:19 hi kroon and mckoan May 26 08:34:49 hi woglinde May 26 09:07:04 hi, I've got this 3.2 kernel for armv5te (machine a780 from meta-handheld) which fails to boot when compiled with the current meta-toolchain built with OE (gcc-4.8.2), it boots fine when compiled with an older toolchain from OE (gcc-4.5.x), this is my bblayers.conf https://gitorious.org/openezx/oe-ezx-build/source/9239cede81c496504f5a5050bc73463389c98671:build/conf/bblayers.conf Is it OK for meta-toolchain? May 26 09:08:15 Where should I report this kind of issues? May 26 09:27:00 ao2: here is fine;) May 26 09:27:06 to me or bluelightning May 26 09:27:48 ao2: we were about obsoleting that family of devices May 26 09:27:59 good that you jump in May 26 09:30:10 now, I can say that other armv5te devices do boot with the standard-built toolchain May 26 09:30:49 note, I don't include the toolchain-layer May 26 09:31:03 * koen came across an a780 while tidying up this weekend May 26 09:31:21 heh May 26 09:31:25 ant_work, hi, I can try without toolchain-layer May 26 09:31:54 hi koen how are you doing? May 26 09:32:41 ao2: pretty good, and you? May 26 09:33:57 ao2: try straight 3.14 May 26 09:34:09 koen, not too bad either, thanks May 26 09:34:50 ant_work, do you mean a 3.14 kernel? May 26 09:34:58 yes, can we remove that openezx-kernel_git ? May 26 09:35:47 put your defconfig in linux-yocto_3.14 May 26 09:36:10 ezx devices are still bound to a 3.2 kernel with a lot of non mainline stuff May 26 09:36:17 argh May 26 09:37:07 but if you want to remove this old stuff from mainline OE we can put them in a dedicated layer May 26 09:37:30 we are collecting all in meta-handheld possibly under the same linux-yocto recipe May 26 09:37:51 koen: btw it would be great if you'd give a try to hx4700 May 26 09:38:16 I'll have some time thursday, remind me then May 26 09:38:23 release week this week May 26 09:38:34 and a day shorter due to thursday being a holiday May 26 09:38:37 o_O May 26 09:38:39 mixed blessings :) May 26 09:39:54 ant_work, I'll let you know about meta-toolchain without toolchain-layer, I have to leave for a while now May 26 09:41:06 thx May 26 12:34:50 if I set PREFERRED_PROVIDER_x = "y" and PREFERRED_VERSION_y = "1.0", it should include v1.0 of "y" in my image if it depends on x, right? May 26 12:35:36 Well, I'm getting this warning: "NOTE: consider defining a PREFERRED_PROVIDER entry to match u-boot" (where u-boot is my "x" in the above example) May 26 12:38:03 I need to make some mountpoints to go with my fstab. Is mkdir with ROOTFS_POSTPROCESS_COMMAND the right way to do it? May 26 12:59:42 hmm, is OE supposed to work with several target machines/arch in the same build tree as of now ? May 26 13:00:17 looks like I just broke mine after building for a new machine May 26 13:00:43 (I was building for x86_64/nuc and tried an arm/cubox-i target) May 26 13:01:36 that's what I get when moving back to MACHINE=nuc http://pastebin.notk.org/pastebin.php?show=d279953ee May 26 14:04:37 Nah, that was not right. And do_install_append was not the solution either. May 26 15:41:38 I'm trying to use the meta-mingw layer to build a mingw-based SDK. Some of the projects I'm trying to include appear to be pulling in nativesdk-eglibc, which seems entirely wrong. Any idea how I should address that ? May 26 15:49:02 * nerdboy winding up the clue stick for #wandboard... May 26 15:49:53 stefan___: not sure... do you have a preferred_provider set for libc? May 26 15:50:19 nerdboy: I don't even know what that is. May 26 15:50:46 tasslehoff: maybe a deploy task with install -d ? May 26 15:51:42 nerdboy: conceptually I would expect the meta-mingw layer to provide its own C runtime, so eglibc shouldn't be used at all (on the host machine, that is).) May 26 15:52:11 but I don't know how that is expressed in terms of poky vocabulary. May 26 15:52:44 grep your .conf files for PREFERRED_PROVIDER_virtual/libc May 26 15:53:35 actually, bitbake -e grep foo will show you what it is in your build env May 26 15:55:57 the value is eglibc May 26 15:56:29 that would be incorrect for what you want... May 26 15:57:52 what does this variable express ? Is that the host C runtime ? (and what would be the name of the target runtime ?) May 26 15:58:31 nothing to do with "host" at least not outside bitbake env May 26 15:58:50 it's the libc used for your toolchain and runtime May 26 15:59:14 which runtime ? host or target ? May 26 15:59:23 * nerdboy is still not clear on where the proper place is May 26 15:59:38 target runtime and and sdk/toolchain May 26 16:00:40 try adding PREFERRED_PROVIDER_virtual/libc = "foo" in yout local.conf May 26 16:00:45 Right, but that should be (e)glibc. I'm trying to build an SDK for mingw, so I need a mingw-based runtime for the host-side, and a normal (e)glibc-based runtime for the target. May 26 16:00:58 where foo == one of the other libc options May 26 16:01:20 sorry, I'm not sure what the options are. May 26 16:01:38 what does mingw need for libc? May 26 16:02:03 I don't know. I think it is downloading a pre-built mingw package from sf.net May 26 16:02:15 it's been a long time since i played with mingw but iirc that was based on a "normal" gnu toolchain? May 26 16:02:55 well, if that's true then maybe eglibc is correct May 26 16:03:14 * nerdboy running out of a**-hairs May 26 16:03:55 yeah, I think it is just doing a canadian cross compilation of gcc. Well, it did manage to compile nativesdk-eglibc, but it failed to install it. May 26 16:05:01 * stefan___ ponders writing a mail, unless RP is around on irc to help May 26 16:24:33 nerdboy: the meta-mingw layer contains a "nativesdk-mingw-w64-runtime" package that contains 'PROVIDES += "virtual/nativesdk-libc"' May 26 16:25:12 that sounds to me like it is building the host-side C runtime for the mingw layer, no ? May 26 16:26:07 yup May 26 16:26:44 so why nativesdk-eglibc, then ? It's not referenced in that .bb file, it must be pulled in from somewhere else. May 26 16:28:03 if that package got built, the info file should have deps May 26 16:28:22 there's a dot file dep graph command as well May 26 16:29:34 maybe there's a missing virtual you need in your config? May 26 16:31:09 I once tried to build a dependency graph. The image was *huge*, so I stopped trying to open it (I killed gimp after it almost brought my machine to its knees during startup.) May 26 16:31:53 and I never got to the point where a package depending on eglibc was built, given that eglibc itself failed to install (due to some path issues) May 26 16:32:16 So, I still have no idea what is dragging in eglibc as nativesdk C runtime. May 26 16:34:18 maybe set a PREFERRED_PROVIDER_virtual/nativesdk-libc = "blah" in your config? May 26 16:34:56 * stefan___ tries that May 26 16:47:14 * nerdboy notes that a 4-core amd laptop is nowhere close to a 6-core desktop in terms of oe build speed May 26 16:49:51 at least it stays fairly cool... May 26 16:55:08 stefan___: Only a minimal set of recipes have been made to compile for mingw May 26 16:55:25 stefan___: If you're trying to extend the SDK, you're probably into new territory May 26 18:19:26 stefan___: there are bunch of other things that are provided by nativesdk version of libc May 26 18:20:16 nativesdk-libiconv nativesdk-libintl May 26 18:20:49 unless your recipes provide them it will pull in nativesdk-eglibc May 26 18:21:18 and usually we do depend on our own version of libc to be running on sdk host machine May 26 18:21:56 khem: OK. So if it is expected that eglibc is built for mingw, we need to figure out why it fails to install. Some paths are wrong... May 26 18:21:57 since we depend on rpath manipulations to run cross compilers and other native tools in SDK May 26 18:22:16 stefan___: I would suggest to go that route yes May 26 18:23:24 maybe slightly OT, but do anyone know why I can't also have an entry in fstab that shows me /dev/mmcblk0p2 in /media/mmcblk0p2 as well as in / (rootfs)? May 26 18:23:39 a bit too much also and as well there :) May 26 18:24:33 tasslehoff: you mean you want it to be automounted ? May 26 18:24:48 you can write udev rules for that May 26 18:27:30 there already is mount script in udev IIRC May 26 18:27:38 which should work in most cases May 26 18:27:45 khem: on my beagleboard I had /media/mmcblk0p[1-4] in /etc/fstab, and they were all mounted. on my wandboard all of them show up in the mountpoints except the one that contains the rootfs May 26 18:27:58 and is therefore already mounted on / May 26 18:28:09 trying to find the x-factor May 26 18:29:00 its mounted as / already so whats the need to get it automounted under /media May 26 18:31:08 khem: convenient for my upgrade scripts. they extract the new rootfs to /media/mmcblk0p2 or 3 based on where the running rootfs is. May 26 18:31:29 Not very important, but I'm curious what has changed May 26 18:31:47 but, if this is OT I'll try some detective work of my own. May 26 18:33:06 you wont be overwriting mounted rootfs I assume so if it does not exist in /media then its mounted as / May 26 18:33:52 tasslehoff: btw. is it same version of OE that mounts it on beagle May 26 18:33:57 and not on wandboard ? May 26 18:34:12 khem: nay. 1.4 on beagle, 1.6 on yocto. May 26 18:34:26 oh well May 26 18:35:04 I guess :) May 26 18:35:13 * nerdboy still trying to get his own kernel booting wandboard May 26 18:35:44 tasslehoff: there were few changes done on automounting / May 26 18:35:51 khem: but! you gave me another good idea. to automount the partitions instead of keeping them in fstab May 26 18:35:53 ok May 26 18:36:10 and 1.4 to 1.6 is a bigger jump so there could be more causing it May 26 18:36:19 but I would suggest to look into that area May 26 18:36:34 thanks May 26 18:36:55 yeah May 26 20:23:43 ho May 26 20:23:49 *hi May 26 20:28:38 could any one help me out actually i wanted to make an operating system for my MSP-exp 430f5529 board May 26 20:29:23 http://www.ti.com/tool/msp-exp430f5529 this is my board May 26 20:37:55 * nerdboy gets the first hotlink off the bbq May 26 21:10:39 I get an install error from nativesdk-eglibc-locale, which wants to install into "/usr/local/OpenEmbedded/yocto/poky/build-mingw/tmp/sysroots/x86_64-nativesdk-mingw32-pokysdk-mingw32/opt/poky/1.6/sysroots/x86_64-pokysdk-mingw32/usr/include/eglibc-locale-internal-x86_64-nativesdk-mingw32-pokysdk-mingw32//opt/poky/1.6/sysroots/x86_64-pokysdk-mingw32/usr/bin" May 26 21:11:49 can someone please tell me whether that directory looks good, and if not, where I might look for the logic defining it ? May 26 21:16:40 note that the build failure only happens when I'm using the meta-mingw layer. May 26 22:46:43 anybody else have issues with xkeymaps lately? May 26 22:47:01 keyboard is missing all the cursor keys now May 26 22:48:07 stefan___: the last part looks bogus May 26 22:48:47 looks like there's a bogus $sdk_bin dir somewhere May 27 02:07:18 nerdboy: thanks. I get the same on a 'normal' (x86) sdkmachine, but there the process doesn't fall over. I wonder where the bug is, and why it doesn't do any harm to anyone else. **** ENDING LOGGING AT Tue May 27 02:59:58 2014