**** BEGIN LOGGING AT Mon Jan 05 02:59:58 2015 Jan 05 09:22:32 hello I just started seeing this compiling yocto for intel edison: No rule to make target `bzImage' Jan 05 09:22:47 I see several reports of this but no clean workaround Jan 05 09:23:01 weirdly my build on the same machine was working yesterday Jan 05 09:25:06 (running on wheezy 7.7) Jan 05 09:27:54 fwiw. http://pastebin.com/Q9Ng3adf Jan 05 09:43:17 bluelightning: good morning Jan 05 09:43:33 morning lpapp, all Jan 05 09:43:42 bluelightning: I had to do this to be able to install 32 bit expat, --add-architecture i386 && apt-get update Jan 05 09:43:50 -> dpkg --add-architecture i386 && apt-get update Jan 05 09:43:59 aha, ok Jan 05 10:17:49 bluelightning: thanks for the hint though, this was much simpler to do than the ideas on the mailing list! Jan 05 10:21:22 well, I figured Debian does do multiarch, might as well use it for simple stuff like that Jan 05 10:34:09 Hi all :) Jan 05 10:34:24 Hi otavio :) Jan 05 10:34:41 jbrianceau: Hey! :) Jan 05 10:35:03 morning otavio Jan 05 10:42:03 bluelightning: morning :) Jan 05 10:42:17 Is Alex Gonzalez here? Jan 05 11:34:30 Anyone tried creating a recipe for pypy? Jan 05 12:26:41 I am either doing something very wrong or I do not get why Yocto provides -Wl,O1 for the LDFLAGS when it generates a linker that does not know that option? Jan 05 12:31:07 bitbake -e | grep LDFLAGS -> export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed" Jan 05 12:31:30 but then I get, arm-foo-linux-gnueabi-ld: unrecognized option '-Wl,-O1' Jan 05 12:31:33 what is going on? Jan 05 12:31:51 why does Yocto have incompatible LDFLAGS with the toolchain generated by it? Jan 05 12:34:33 is there way that I can get through this? Jan 05 12:35:50 obviously, I could drop in the buildsystem of our software what Yocto is trying to pass by overriding it, but I guess that is not nice either. Jan 05 12:48:25 bluelightning: got a clue by any chance? Jan 05 13:17:46 otavio: there? Jan 05 13:32:36 lpapp: perhaps the command line is written expecting gcc as the linker and something else is being used instead ? Jan 05 13:46:47 rburton: yes Jan 05 13:47:30 bluelightning: hmm, fair enough, arm-foo-linux-gnueabi-ld is not gcc. So which linker is recommended while using Yocto with the builtin toolchain? Jan 05 13:48:16 lpapp: you shouldn't have to choose it, AFAIK Jan 05 13:52:56 bluelightning: what am I doing wrong? Jan 05 13:57:07 lpapp: actually maybe you do need to pass LD="${CCLD}" on the make command line Jan 05 13:57:28 I can see examples where recipes do that Jan 05 13:57:57 bluelightning: hmm, interesting why this is not implicit. Jan 05 13:58:08 (if Yocto passes incompatible flags to "LD") Jan 05 13:58:20 if the software being built pays attention to LD from the environment, it is Jan 05 13:58:41 or, maybe not Jan 05 13:59:57 bluelightning: in fact, we do LD = $(CXX) in our buildsystem Jan 05 14:00:10 ifeq ($(origin CXX), default) Jan 05 14:00:10 CXX = $(TOOL_PREFIX)g++ Jan 05 14:00:11 endif Jan 05 14:00:38 so I wonder where the ld comes from ... Jan 05 14:01:51 otavio: https://autobuilder.yoctoproject.org/main/builders/nightly-fsl-arm-lsb/builds/146 is failing interestingly, is the new linux-libc-headers interacting badly with your bsp? Jan 05 14:13:12 rburton: this is Qt4 error, why you think it is linux-libc related? Jan 05 14:14:41 Ahhh Jan 05 14:14:43 waffle Jan 05 14:36:26 lpapp: so, I have to agree it seems unusual, but apparently it's always been that way and doesn't seem to cause too many issues Jan 05 14:47:26 bluelightning: yeah, something is fluffy in my environment, I assume, but it is not easy to pin down for me. Jan 05 14:47:35 (I am still investigating) Jan 05 14:50:08 bluelightning: and it is more trickier than that, our software picks up -gcc without Yocto, but -ld with Yocto. Jan 05 14:50:12 (and only for one submodule) Jan 05 14:50:46 hmm, odd... I can only assume it's looking at something in the environment Jan 05 15:13:11 otavio: qt4 fails with a kernel userspace header include Jan 05 15:13:36 bluelightning: the environment variable coming from Yocto is -ld? Jan 05 15:14:04 oh, yes, it is. Jan 05 15:24:19 bluelightning: I am still puzzled how other software pieces manage it if LDFLAGS is incompatible with LD that Yocto uses ... Jan 05 15:24:31 bluelightning: does everything have to hardcode it either in their buildsystem or in the recipe? Jan 05 15:24:56 (to be compatible one way or the other?) Jan 05 15:26:19 lpapp: AIUI most of the software we build ends up using gcc as the linker; occasionally we have to specify it but not very often Jan 05 15:26:48 bluelightning: but bitbake shows -ld is the default LD Jan 05 15:26:51 bitbake -e Jan 05 15:27:05 (not gcc, so something has to modify that to be compatible with LDFLAGS in Yocto) Jan 05 15:27:36 I really don't know, sorry Jan 05 15:27:48 bluelightning: ok, but you understand the issue, yeah? Jan 05 15:27:54 I believe so Jan 05 15:39:55 Would it be bug in bitbake/oe-core, if bitbake decides to rebuild busybox for MACHINE=imx6qsabresd, even though I already have it built for MACHINE=wandboard-quad (same arch) ? I see busybox's stamp files in stamps/cortexa9hf-vfp-neon-oe-linux-gnueabi/busybox Jan 05 15:54:25 lpapp: some recipes do override LD as CC fwiw Jan 05 15:55:03 RP: yeah, I currently do override LD=CC in our buildsystem. Jan 05 15:55:29 to circumvent this issue, but I am still interested in the root cause of this. Jan 05 15:55:36 as I cannot possibly imagine it working without explicit override, yet it seems to work for everything in Yocto. Jan 05 15:55:40 so there must be some trick to it... Jan 05 15:57:13 lpapp: there is no trick as far as I know, I've wondered about this before myself. Its been like this in OE since "the dawn of time" Jan 05 15:57:33 kergoth: any ideas on why LDFLAGS assumes gcc but LD is ld, not gcc? Jan 05 15:58:23 I expect its inherited from autotools behavior and conventions. I *think* that's the case for automake Jan 05 15:58:27 but honestly don't recall, its been a long time now :) Jan 05 15:59:07 RP: yeah, I do not question it functional, but it is strange and I do not feel happy when I do not understand something like this. Jan 05 15:59:10 :-) Jan 05 16:00:08 kergoth: if I had to guess I'd have suspected autotools too Jan 05 16:00:36 rburton: how I can reproduce it here? Jan 05 16:00:52 actually i think most makefile based buildsystems treat LDFLAGS as being gcc arguments as well, just most of them use ${CC} to link, and don't use LD at all Jan 05 16:00:57 hmm Jan 05 16:01:37 otavio: well my hunch is that its due to the libc headers in master so build from clean with that Jan 05 16:02:06 kergoth: yeah, that is the same effect as override LD=CC Jan 05 16:02:13 * kergoth nods Jan 05 16:02:47 otavio: where does linux/mxcfb.h come from? Jan 05 16:03:04 rburton: kernel Jan 05 16:03:37 otavio: so the new kernel infrastructure in master is probably interacting badly with your kernel, or something Jan 05 16:03:49 rburton: likely Jan 05 16:03:56 rburton: I will take a look Jan 05 16:05:55 rburton: testing build here Jan 05 16:13:02 except that override LD=CC can no longer be overriden, whereas using CC in the linker command directly allows overriding. Jan 05 16:13:15 (so I should probably drop the use of the LD variable) Jan 05 16:54:31 rburton: bitbake qt4-x11-free 18311.50s user 1476.88s system 687% cpu 47:59.61 total Jan 05 16:55:10 rburton: so it built fine here Jan 05 16:55:17 sigh Jan 05 16:57:42 otavio: reliably fails on the ab :/ some race maybe? Jan 05 16:57:58 rburton: new patch in master-next? Jan 05 16:58:29 nothing relevant Jan 05 16:59:15 I am not doing a full from scratch build to try Jan 05 17:04:21 are there any tricks to getting xfce working? i keep getting missing RDEPENDS Jan 05 17:04:53 i've already checked the dependencies... Jan 05 17:05:35 I am confused as to why I see this: ./meta/recipes-bsp/grub/grub_2.00.bb -> do_install_append without require? Jan 05 17:05:45 what is the point of append in there rather than just do_install? Jan 05 17:07:35 because autotools provides a do_install() Jan 05 17:08:08 Aethenelle: which RDEPENDS are being reported as missing? Jan 05 17:09:08 rburton: thanks, is do_install_append supposed to run after do_install? Jan 05 17:09:28 so is it a good idea to use do_install in the .inc and do_install_append in the one requiring the .inc? Jan 05 17:09:45 lpapp: do_install is just a variable, so the append is evaluated like usual Jan 05 17:09:45 bluelightning: lots... I'll run it again and gist it... Jan 05 17:10:57 Aethenelle: you also have meta-oe and meta-multimedia in your bblayers.conf right? (from the README those are apparently required) Jan 05 17:11:04 the meta-xfce README that is Jan 05 17:11:06 yup Jan 05 17:11:54 lpapp: _append/_prepend are just postponed concatenation Jan 05 17:11:59 cumulative Jan 05 17:16:45 I am curious why we have two versions of RPM in OE-Core? Jan 05 17:17:36 https://gist.github.com/anonymous/8d5a60dc77b97f3000a0 Jan 05 17:20:05 otavio: bleeding edge and stable I guess, but you could ask fray for confirmation Jan 05 17:20:08 otavio: because different people have strong opinions on rpm version :) Jan 05 17:20:09 trying again without tools-debug ... then without tools-sdk Jan 05 17:20:35 hm there's two versions of rpm5 too Jan 05 17:20:37 bluelightning: seems not. We seem to be using 5.4.14 by default even though it is a development release Jan 05 17:21:10 bluelightning: and this is wrong, IMO. If even RPM developers think it is not stable why we should default to it? Jan 05 17:21:16 fray: ? Jan 05 17:21:59 Aethenelle: it looks like libwnck is in meta-gnome, perhaps that is an undeclared dependency Jan 05 17:24:31 Aethenelle: ditto for libxklavier and libgsf Jan 05 17:24:51 added... running again Jan 05 17:24:53 thanks Jan 05 17:25:12 it would probably be worth talking to the maintainer about updating the README and layer index entry to reflect that Jan 05 17:34:35 ... and meta-networking, meta-python ... running after adding those Jan 05 17:52:16 probably an upstream issue but mozjs fails to compile on edgerouter... bad cast Jan 05 18:04:56 rburton: http://privatepaste.com/78585c0769 Jan 05 18:05:08 rburton: from scratch - no sstate Jan 05 19:48:05 otavio: looks like there's a race now that the kernel doesn't install sources directly. Jan 05 19:48:25 otavio: instead kernel-devsrc installs the sources into the sysroot Jan 05 19:49:36 otavio: see oe-core 7f934946fdb3184a06ce1a2cdc29559e7c468492 Jan 05 19:49:59 otavio: i think your recipes that use kernel headers directly need to use that pattern Jan 05 19:51:09 rburton: but seems wrong to have this explicit now Jan 05 19:51:59 otavio: agreed i don't understand either but i need to go no, talk to RP and zeddii :) Jan 05 19:52:04 still perf is failing in world builds Jan 05 19:52:23 JaMa: there's a rebuild bug still, bruce is fixing that now i hear Jan 05 19:52:38 JaMa: (i often hit rebuilds failing too) Jan 05 19:53:05 I'm trying to add openjdk-8 from meta-aarch64 to thix box, adding openjdk openjdk-8 or openjdk-8-jdk to IMAGE_INSTALL_append results in a complaint that mothing RPROVIDES openjdk Jan 05 19:53:11 * zeddii is churning on the remaining fixes this week. but won't be full speed until the morning. I spent today reading 1200 email. Jan 05 19:53:19 and it seems that most linux.inc (not linux-yocto) kernels are failing as well Jan 05 19:53:45 Aethenelle: please port it to meta-java :) Jan 05 19:53:58 in various stages (I've seen do_unpack failing with "No such directory" as well as do_configure failing with no oldconfig Makefile target IIRC also reported on ML Jan 05 19:54:09 otavio: even though it's in meta-linaro/meta-aarch64? Jan 05 19:54:20 JaMa: point me at any configs that break, and I can have a look. logs are good as well. Jan 05 19:54:24 Aethenelle: so we can drop it from there Jan 05 19:54:42 we knew this was going to be a pain, but it needed wider use to sort out the rest. Jan 05 19:54:52 ahh... k Jan 05 19:55:40 zeddii: http://lists.openembedded.org/pipermail/openembedded-devel/2015-January/099651.html Jan 05 19:56:14 * zeddii nods Jan 05 19:56:14 zeddii: http://lists.openembedded.org/pipermail/openembedded-core/2015-January/100335.html Jan 05 19:57:09 the split S and B is default .. which is throwing things for a loop. Jan 05 19:57:26 I'll have a look and see what else is lurking. Jan 05 19:58:08 rburton: zeddii: what makes me worry is because I am building with -j 8 Jan 05 19:58:29 and if it were a race I would have seen it Jan 05 20:00:15 otavio. what's the config that broke ? if you put it in a bug, I can see if anything jumps out. I don't have all the context. Jan 05 20:02:00 https://autobuilder.yoctoproject.org/main/builders/nightly-fsl-arm-lsb/builds/146 Jan 05 20:10:19 otavio: I'm lost in the giant log files. Which package is broken in your case ? waffle ? and this is only happening on the autobuilder, and not in your local builds ? Jan 05 20:11:08 zeddii: check the qt4 failure Jan 05 20:12:45 searching on qt4 got me 7153 hits. I'll try and refine that. Jan 05 20:13:38 zeddii: look for error: Jan 05 20:38:01 otavio. yah, I see it in the log now. Jan 05 20:38:17 otavio, have you reproduced this one in your local builds, or is it auto builder only ? Jan 05 20:52:09 zeddii: only in AB Jan 05 20:53:15 ok. Jan 05 20:53:31 so me sparking up a build, might not be so informative. Jan 05 20:54:12 zeddii: Why the :do_install dependency has been added in perf? Jan 05 20:54:15 from what RP was trying to document in 86893e4ea5896199a6f02f8475f4f17aa1124c37, we've been converting recipes to be more precise in their dependency. Jan 05 20:54:29 otavio. good timing. we covered it in the commit I references. Jan 05 20:54:35 referenced even Jan 05 20:54:51 zeddii: but to speed up parallel building, not to fix a build failure Jan 05 20:55:00 except the commit was written before it was tweaked to do_install. hmm. Jan 05 21:17:13 openjdk is refusing to build because wandboard-quad defaults to a 32bit arch how do i tell bitbake to use aarch64? Jan 05 21:33:56 Aethenelle: well, wandboard does not support armv8, only armv7a Jan 05 21:35:44 otavio: thanks... it'd help if i could read bug tickets right... Jan 05 22:28:10 you guys know of a mips64el machine already configured? ppc64el? **** ENDING LOGGING AT Tue Jan 06 02:59:59 2015