**** BEGIN LOGGING AT Tue Jun 21 02:59:56 2011
Jun 21 07:13:10 <oktalogi1> | make: *** [miniperl] Error 1
Jun 21 07:13:10 <oktalogi1> | FATAL: oe_runmake failed
Jun 21 07:13:10 <oktalogi1> | ERROR: Function 'do_compile' failed (see /home/oktalogic3/hugo/hack/yokto/poky-bernard-5.0/build/tmp/work/i686-linux/perl-native-5.12.2-r7/temp/log.do_compile.30959 for further information)
Jun 21 07:13:57 <oktalogi1> any ideas?
Jun 21 07:14:02 <oktalogi1> sorry for spamming a bit
Jun 21 07:14:25 <oktalogi1> got it after a while on bitbake meta-toolchain-sdk
Jun 21 07:24:41 <bluelightning> oktalogi1: what's in that log file, could you pastebin that?
Jun 21 07:53:39 <oktalogi1> bluelightning: http://pastebin.com/jEyKecH0
Jun 21 07:53:53 <oktalogi1> almost the same thing, except this linker error
Jun 21 07:54:13 <oktalogi1> what i want do is use the yocto eclipse plugin. so maybe tarball is better? but i havent got that to work either
Jun 21 07:55:03 <oktalogi1> the video demonstrating the eclipse plugin is not demonstrating the latest versions. so the first screen when to set sdk sysroot etc confuses me. i have a tarball toolchain for arm in /opt/poky allready but it wont accept it...
Jun 21 07:56:35 <bluelightning> oktalogi1: which version of poky are you using? there should be a fix for the perl issue in 5.0.1
Jun 21 07:57:44 <bluelightning> oktalogi1: I don't know much about our eclipse integration I'm afraid, but later on today there might be some people around on this channel who can help you
Jun 21 07:57:49 <bluelightning> (with that)
Jun 21 07:59:50 <oktalogi1> allright
Jun 21 08:00:00 <oktalogi1> i want to compile arm applications to run in the poky-qemu
Jun 21 08:00:25 <oktalogi1> is there a sample .conf to for such a simulated hardware?
Jun 21 08:01:39 <oktalogi1> i mean, when i run meta-toolchain-sdk, it will get me an arm crosscompiler toolchain, like the one from codesourcery
Jun 21 08:14:39 <bluelightning> oktalogi1: that's the idea
Jun 21 08:15:20 <bluelightning> the default sample config file builds for qemux86, just change MACHINE to qemuarm for what you're after I think
Jun 21 08:21:20 <oktalogi1> ok... but the tarball should have worked just as fine. probably a problem on the plugin side hmm
Jun 21 08:34:15 * bluelightning -> office
Jun 21 09:57:57 <oktalogi1> checking for arm-poky-linux-gnueabi-gcc... arm-poky-linux-gnueabi-gcc
Jun 21 09:57:57 <oktalogi1> checking whether the C compiler works... no
Jun 21 09:57:58 <oktalogi1> configure: error: in `/home/oktalogic3/workspace/hejvarld':
Jun 21 09:58:16 <oktalogi1> i have manged to go a bit further with the yocto eclipse plugin but i now get this error....
Jun 21 09:58:57 <oktalogi1> while doing "Select Project -> Reconfigure Project. This runs the autogen.sh "
Jun 21 10:02:09 <bluelightning> oktalogi1: my suggestion would be to post a message to the yocto mailing list, with a few more details
Jun 21 10:15:27 <thhp> In oe-core, glib-2.0.inc raises a SkipPackage exception if USE_NLS is "no", and tclibc-uclibc.inc sets both USE_NLS ?= "no" and USE_NLS_glib-2.0 = "yes"
Jun 21 10:15:50 <thhp> So it seems to me that USE_NLS should be "yes" for glib-2.0, but nothing else when building uclibc
Jun 21 10:16:31 <thhp> But I always see glib getting removed from the package set when building uclibc, unless I comment out USE_NLS ?= "no" in tclibc-uclibc.inc
Jun 21 10:16:49 <thhp> Am I missing something about how bitbake variable expansions work...?
Jun 21 12:57:25 <otavio> sgw: are you preparing the next pull request?
Jun 21 13:03:39 <bluelightning> thhp: I wonder, if it's changed to USE_NLS_pn-glib-2.0 = "yes" does it make a difference?
Jun 21 13:05:50 <bluelightning> that override does look like a bit of a hack to me though
Jun 21 13:07:07 <thhp> bluelightning: I tried USE_NLS_pn-glib-2.0 = "yes", but to no avail.  glib-2.0-native is still removed from the list of targets.
Jun 21 13:07:32 <bluelightning> oh wait... maybe pn-glib-2.0-native
Jun 21 13:07:36 <thhp> If I remove the line USE_NLS ?= "no" in tclibc-uclibc.inc (it defaults to "yes"), then it's OK
Jun 21 13:07:52 <bluelightning> of course, the latter is what you would expect
Jun 21 13:08:03 <thhp> yep
Jun 21 13:08:16 <bluelightning> try with USE_NLS_pn-glib-2.0-native = "yes"
Jun 21 13:11:39 <thhp> USE_NLS_pn-glib-2.0-native = "yes" seems to work...
Jun 21 13:11:50 <thhp> thanks! :-)
Jun 21 13:11:58 <thhp> What is the relevance of "pn" in this case?
Jun 21 13:13:06 <bluelightning> thhp: pn tells it to override for a package name
Jun 21 13:13:44 <bluelightning> I'm not sure whether not having it there is expected to work, one would assume that it did previously in this case (the change that introduced it is from 2007)
Jun 21 13:13:53 <bluelightning> RP__: maybe you can shed some light on this?
Jun 21 13:16:32 <thhp> Ah, OK.  I've always assumed "FOO_BAR_my-package" meant "override FOO_BAR for my-package", which is why I was confused earlier.
Jun 21 13:20:01 <thhp> Actually, with some further experimentation it appears that USE_NLS_glib-2.0-native = "yes" also works.  So possibly "pn" is a red herring in this case?
Jun 21 13:21:20 <bluelightning> well pn- is correct syntax and I can see via bitbake.conf how that works (pn-${PN} is added to OVERRIDES)
Jun 21 13:21:49 <thhp> I'm happy to go with it if it's correct ;-)
Jun 21 13:22:16 <bluelightning> I'd be interested to know how it works when pn- is not present
Jun 21 13:26:16 <thhp> Hum, I see the code you refer to in bitbake.conf, and I also struggle to see how it works without "pn".  I'll just double check my build to ensure I'm not misleading you.
Jun 21 13:26:26 <bluelightning> hmm, seems like it might be something internal to bitbake
Jun 21 13:27:56 <bluelightning> paul@helios:~/poky/poky/build$ bitbake -e glib-2.0-native | grep ^OVERRIDES
Jun 21 13:27:58 <bluelightning> OVERRIDES="linux:i686:build-linux:pn-glib-2.0-native:crownbay:poky:forcevariable:libc-glibc:virtclass-native"
Jun 21 13:28:22 <bluelightning> so no glib-2.0-native on its own there
Jun 21 13:28:34 <bluelightning> thhp: presumably you get similar results when you run that?
Jun 21 13:29:18 <bluelightning> if so it's something internal to bitbake where it's adding ${PN}
Jun 21 13:29:25 <bluelightning> which is not necessarily a bad thing
Jun 21 13:29:44 <bluelightning> but in any case I do prefer pn- because it makes it obvious you're referring to a package name
Jun 21 13:30:08 <thhp> [parkint1@raven build]$ bitbake -e glib-2.0-native | grep ^OVERRIDES
Jun 21 13:30:14 <thhp> OVERRIDES="libc-uclibc:linux:i686:build-linux:pn-glib-2.0-native:qemumipsel:${DISTRO}:forcevariable:virtclass-native"
Jun 21 13:31:15 <thhp> I guess it must be bitbake magic, then.  It does definitely work without pn (just doubled checked from clean).  But I agree with you -- the pn syntax is clearer.
Jun 21 13:32:00 <bluelightning> either way it would seem that the current override is not working effectively
Jun 21 13:32:13 <bluelightning> would you mind filing a bug report?
Jun 21 13:32:14 <thhp> Indeed
Jun 21 13:32:42 <thhp> No problem, where should I point my bug report at?  The Yocto bug tracker?  I'm using oe-core, FWIW.
Jun 21 13:33:22 <bluelightning> hmm ok, it should still be applicable to poky
Jun 21 13:33:29 <bluelightning> but maybe best to email to oe-core
Jun 21 13:33:36 <bluelightning> (the mailing list)
Jun 21 13:34:24 <thhp> Will do
Jun 21 13:49:40 <RP__> thhp: I was going to reply to you earlier but you were offline
Jun 21 13:49:53 <RP__> thhp: The form with pn- is definitely the correct one
Jun 21 13:50:14 <RP__> Some variables work without it like PREFERRED_VERSION but there are only a small number of them
Jun 21 13:50:20 <RP__> and USE_NLS isn't one of them
Jun 21 13:51:48 <bluelightning> RP__: it seems to work here through some mechanism, it's just currently in tclibc-uclibc.inc we set it only for glib-2.0 and not glib-2.0-native
Jun 21 13:52:36 <RP__> bluelightning: how is it showing as working?
Jun 21 13:52:56 <bluelightning> according to thhp, it avoids the skippackage
Jun 21 13:53:23 <bluelightning> as long as -native is added to the end, it doesnt' seem to matter whether pn- is there or not
Jun 21 13:53:53 <bluelightning> (obviously this is when building glib-2.0-native, so the former is expected)
Jun 21 13:55:05 <RP__> It sounds odd :/
Jun 21 13:55:08 <bluelightning> indeed
Jun 21 13:55:33 <bluelightning> RP__: as I said earlier presumably it used to work, when you added it back in 2007 ;)
Jun 21 13:55:54 <bluelightning> or rather, it was expected to work at that time
Jun 21 13:56:14 <bluelightning> quite a lot has changed since then of course
Jun 21 13:56:31 <RP__> bluelightning, thhp: There is magic code in base.bbclass
Jun 21 13:56:46 <RP__> 2007 was pre pn-{PN} worked as an override
Jun 21 13:56:56 <bluelightning> ah, right, that would explain it
Jun 21 13:57:07 <RP__> that is really oldschool :)
Jun 21 13:57:33 * RP__ sees code marked "OBSOLETE in bitbake 1.7.4"
Jun 21 13:58:59 <RP__> Ideally we should rip that code out and replace any references to _pn- versions
Jun 21 14:03:59 <thhp> RP__: thanks for the explanation
Jun 21 14:04:29 <thhp> I've gone with bluelightning's syntax for my tree here, and I'll post the (trivial) patch to the oe-core ml
Jun 21 14:48:32 <mlip> RP__, anything about http://bugzilla.pokylinux.org/show_bug.cgi?id=1139 ? *fingers-crossed*
Jun 21 14:50:55 <RP__> mlip: To be honest I've been heads down the past several days on multilib
Jun 21 14:52:09 <mlip> RP__, oke just did a pull to get any recent changes; maybe I find the time to fiddle a bit around with it, if the bug is still existent
Jun 21 15:30:36 <nitink> Good Morning All
**** ENDING LOGGING AT Wed Jun 22 02:59:57 2011