**** BEGIN LOGGING AT Fri Dec 19 02:59:59 2014 Dec 19 06:21:50 for gcc, if I specify configure target=host , do I compile the gcc to run on my build machine or the target platform? Dec 19 06:41:49 chankit: you're telling it to build for native, which means to run on host machine according to this: https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html Dec 19 06:42:08 host/build machine rather Dec 19 07:48:32 TypoNAM: ok...suppose that I'm using a BSP package provided by Intel, so how does Yocto configure GCC to cross compile for that target platform? I dissected the gcc folder under folder meta but I found nothing informative. But I guess that should be due to my incompetance and that's the reason I voice out my problem here. Dec 19 07:50:08 BTW, sorry for my late reply here. Dec 19 07:59:53 chankit: i'd suggest to generate a sdk with the yocto mechanisms. then have a look at it (its basically two sysroot and an environment setup script) Dec 19 08:00:20 chankit: looking at that, without all the build dir stuff should make crosscompilation quite a bit more clear Dec 19 08:32:20 LetoThe2nd: I guess that's one of the ways...that somewhat makes me appreciate the work done by the developers that we take for granted...My actual goal is actually to bitbake clang compiler but somewhat I bitbaked the clang for my build machine rather than the platform. Dec 19 08:33:36 That's why I tried to examine gcc to see how they got through that cross compiling thing. Since gcc and clang are both compilers, gcc recipes would be a good place for me to see how can I get clang to work on my target machine Dec 19 08:42:11 chankit: sounds like you mixed up recipe contents for a native target and a stadard (cross) target Dec 19 08:42:54 does anybody know what do_compile_class-native() method defines? Dec 19 08:43:05 LetoThe2nd: most probably I'm afraid Dec 19 08:43:58 chankit: the "-native" is the buzzword here. it makes clear that the compilation target is the host machine. Dec 19 08:44:51 chankit: i'd suggest to take a look at some recipes that are actually built for the target, as well as the recipe-writing section in the yocto dev manual Dec 19 08:45:29 chankit: and, if you're ripping out bits and pieces of other recipes: whenever you read "-native", it should ring an alarm bell. it will probably not do what you meant Dec 19 08:48:55 LetoThe2nd: Here's my stupid clang recipe http://pastebin.com/mrZ0Pq7V . I don't see much of -native methods though Dec 19 08:49:32 Obviously I **stole** the original recipe and modified it :-( Dec 19 08:50:45 The reason I list out a lot of files is because I got files/directories were installed but not shipped error..so I did that to circumvent that error Dec 19 08:52:27 the original file has --enable-targets=host which is probably wrong in my opinion so I changed that to x86_64 Dec 19 08:52:44 chankit: i see. well i'm no pro too, i'm just handing out pointers that i've gathered over time. Dec 19 08:53:34 chankit: but i think manually setting thing like target or host for the configure run is kind of sabotage to the crosscompile automatisms OE provides Dec 19 08:57:11 LetoThe2nd: probably...removed that line and see what comes up..that parameter defaults to "all" so hopefully that opens up the compatibility list Dec 19 10:05:06 Hi, I'm getting an error on the dizzy branch: http://paste.ubuntu.com/9568324/ Anyone else seeing this? Dec 19 10:13:37 karooga: what host distro are you building this on? Dec 19 10:19:05 any idea if PRSERV_HOST will also work if put in site.conf? Dec 19 10:28:06 bluelightning: ubuntu 13.10 Dec 19 10:29:13 I've added meta-raspberrypi and meta-gstreamer1.0 to BBLAYERS and set MACHINE to raspberrypi. Dec 19 10:43:12 bluelightning: do you think it would help to switch to something like 14.04? Dec 19 10:53:15 The manual says that it's supported? Dec 19 11:16:31 karooga: I'm not sure if that's the issue... do you know what is causing byacc-native to be built? Dec 19 11:18:45 bluelightning: I'm not sure, still new to yocto. How can I check? Dec 19 11:18:55 Was just following: https://delog.wordpress.com/2014/09/16/embedded-linux-system-for-raspberry-pi-with-yocto-project/ Dec 19 13:00:25 Dec 19 13:04:20 is there support for working with source trees in Yocto/bitbake, something in the lines of srctree.bbclass that used to be in openembedded? Dec 19 13:09:29 bboozzoo, is externalsrc.bbclass what you're looking for? Dec 19 13:10:21 looks good, thanks Dec 19 15:31:18 seebs: ping Dec 19 16:19:11 JaMa: ping Dec 19 16:19:46 JaMa: so, I'm experimenting with that multiple runtime providers thing we discussed couple days ago Dec 19 16:23:12 JaMa: so, I got GL providers named and versioned identically, but made machine-specific. now, qtwebkit is NOT machine-specific, but links to GL. the problem is that qtwebkit doesn't get staged for the second machine I build, so libs are not in sysroots... any ideas? Dec 19 16:24:19 why isn't it staged? Dec 19 16:28:03 JaMa: not sure, trying to figure it out now. but libQt5WebKit.* are missing from the second machine sysroots, while being present in the first built machine sysroots Dec 19 16:29:43 JaMa: do I need qtwebkit to be excluded from siggen for that to work? Dec 19 16:32:18 no siggen exclude is only needed to make qtbase signature identical for multiple MACHINEs Dec 19 16:32:36 it shouldn't influence staging at all Dec 19 16:33:36 JaMa: yeah, I think it's rebuilding qtwebkit now for the second machine and replacing IPKs, but not sure why staging is missing... Dec 19 16:48:10 1 3 Dec 19 16:57:20 JaMa: so, looking into work dir - image/ and package/ contain machine-specific paths. normally, qtbase will have /usr/lib paths in there, in case of qtwebkit it has /home/user/blah/sysroots/machine/usr/lib instead... Dec 19 16:58:01 in which files, prf, prl and similar files are sanitized in sstate Dec 19 17:22:34 JaMa: now, that is just killing me! on my other machine it stages everything properly... :( Dec 19 17:42:44 Does anyone know what the current opinion on .inc files in oe-core is? I'm trying to put non-version specific stuff in opkg.inc instead of opkg_0.2.4.bb but the split is getting confusing Dec 19 17:44:26 I know there's been previous discussion on .inc files but I can't remember if we're trying to keep them or merge them into the .bb file when we're only maintaining one version of a recipe Dec 19 17:46:20 paulbarker: I thought for 1 version there's not much benefit in .inc Dec 19 17:47:41 denix: I agree, the .inc is already there for opkg though Dec 19 21:24:27 Hmm, anyone gotten busybox building with tirpc? Dec 19 23:39:15 kergoth: ack Dec 20 00:06:30 seebs: was curious if you'd run into https://bugzilla.yoctoproject.org/show_bug.cgi?id=7093 before Dec 20 00:06:31 Bug 7093: normal, Undecided, ---, mark.hatle, NEW , Files owned by build user when created by qemu Dec 20 00:10:18 I don't think so. Dec 20 00:11:22 Hmm. *thinking* If it's running under pseudo, and it's native bit width, I can't immediately see why that'd happen. Dec 20 00:11:52 In theory I'm not working between now and January 2nd, but I'm sorta curious about that one because I will basically always take any excuse to kick pseudo around. Dec 20 00:12:21 I've never messed with usermode qemu before, so I don't know whether it's doing anything highly magical about syscalls. Dec 20 00:12:53 relatively minor, i think these are the only files left that have build machine ownership in the target fs nowadays. we have a workaround to just chown the files coming out of qemu for now Dec 20 00:13:28 You know, I don't even know whether we have a standard check for that floating around. Probably ought to. Dec 20 00:15:29 Hmm, that's not a bad idea. Of course, depending on what the uid is of the build user, it might be completely reasonable to have files owned by that if that user is on target too. could have a separate job that poisons by using a user with an oddball uid :) Dec 20 00:16:34 Yeah. **** ENDING LOGGING AT Sat Dec 20 02:59:59 2014