**** BEGIN LOGGING AT Mon Jun 02 02:59:59 2014 Jun 02 06:31:00 morning all Jun 02 08:40:18 morning all Jun 02 08:41:15 moin(UGT) bluelightning Jun 02 08:43:44 hi LetoThe2nd Jun 02 08:47:02 happy new yocto day ;) Jun 02 09:01:00 hello everybody Jun 02 09:02:18 anybody has a minute to assist me with an eclipse autotools issue? Jun 02 09:05:55 state the case of your emergency and wait for rescue Jun 02 09:06:14 (read that as: don't ask to ask, just ask. if somebody knows, you will get an answer) Jun 02 09:06:40 aight, thanks, well Jun 02 09:06:55 cross compiling on ubuntu 14.04 for powerpc Jun 02 09:07:16 used bit bake to compile a toolchain myself Jun 02 09:07:47 created the autotools hello world project in eclipse Jun 02 09:08:03 configured eclipse to use the toolchain in my build directory Jun 02 09:08:23 config.log says error 77 Jun 02 09:08:48 eclipse console log says "no role to make target 'all'" Jun 02 09:09:14 And "C compiler cannot create executables" Jun 02 09:09:31 I am using Yocto 1.5 (taken from ELDK) Jun 02 09:09:54 pre-compiled eclipse (juno) plugin Jun 02 09:11:32 sourcing the environment script in my build directory and building the project on the command line works perfectly Jun 02 09:23:02 what looks suspicious to me in config.log is "C compiler cannot create executables" Jun 02 09:23:50 yes, that means the compiler isn't being called correctly, or isn't working correctly. Jun 02 09:24:07 reading config.log in the source directory will show you what happened Jun 02 09:24:32 in relation to that i now see in config log ld: cannot find ctrl.o: no such file or directory" Jun 02 09:25:30 that's when he tries to compile conftest.c Jun 02 09:26:27 the compile flags used when compiling gn the command line are not quite the same when compilation is invoked through eclipse Jun 02 09:26:58 i did not make any changes to the eclipse project setup, everything is like described in the documentation Jun 02 09:31:10 ok, the file does exist in sysroot Jun 02 09:31:14 ~. Jun 02 09:31:41 sorry, ssh session fail there Jun 02 09:32:11 the powerpc-linux-gcc is called with several --sysroot arguments at once Jun 02 09:41:51 looks like my sysroot (not the one in build/tmp) but the one that i will export via nfs is not populated correctly and autotools do not find the required files in there Jun 02 09:43:16 SOLVED Jun 02 09:43:19 thanks Jun 02 11:55:33 Hello all! Jun 02 12:01:03 WHOIS Jun 02 13:17:08 gm Jun 02 14:08:47 anyone have a link/wiki for how to convert a "./configure, make, make install" type install to a recipe? I'm trying to add libdbus-c++ to an image Jun 02 14:09:49 is that configure/makefile using autoconf/automake? Jun 02 14:10:44 i think so, how can I tell for sure? Jun 02 14:10:58 there'll be a configure.ac (or .in) and Makefile.am Jun 02 14:11:10 yes, there is Jun 02 14:11:13 http://www.yoctoproject.org/docs/1.6/dev-manual/dev-manual.html#new-recipe-autotooled-package Jun 02 14:11:29 just "inherit autotools" Jun 02 14:11:42 like, inherit autotools Jun 02 14:11:49 dang, rburton was faster ;) Jun 02 14:12:16 the long way would be to call configure in do_configure, make in do_compile and make install in do_install, but autotools does that for you. Jun 02 14:12:18 hmm, so I really don't need any do_configure or do_install sections? Jun 02 14:12:36 ripperD: correct. nor a do_compile to actually build it. Jun 02 14:13:09 hmm ok. What if I need to turn off a couple options in the configure step? I use --disable-ecore --disable-examples --disable-doxygen-docs --disable-tests Jun 02 14:13:24 ripperD: http://www.yoctoproject.org/docs/1.6/ref-manual/ref-manual.html#ref-classes-autotools Jun 02 14:14:15 ok, so I can use extra_oeconf Jun 02 14:14:25 this should get me a lot further, thanks! Jun 02 14:22:18 hrm Jun 02 14:22:23 how do I patch the source first? Jun 02 14:22:52 I need to add an include for unistd.h i guess Jun 02 14:24:28 ripperD: http://www.yoctoproject.org/docs/1.6/ref-manual/ref-manual.html#patching-dev-environment Jun 02 14:26:13 http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe Jun 02 14:26:16 ah ok. I had a sed line in the do_compile I had been working on to put it in, but wasn't sure if with this automake stuff I could put in do_patch or whatnot Jun 02 14:26:31 just add a patch to SRC_URI Jun 02 14:26:34 and it will be applied for you Jun 02 14:26:51 i can probably throw my one line sed -i in there i'm guessing Jun 02 14:27:16 although a patch is easy enough to create too. thanks Jun 02 14:28:50 if you can, using a patch is preferable because you can tell when it fails to apply Jun 02 14:29:15 sed with s/ won't error out if nothing actually gets changed Jun 02 14:30:03 (although that's usually more of a long term maintenance thing) Jun 02 14:30:59 yeah, going by standards is usually a good thing Jun 02 14:39:16 Hi, I am trying to adapt the yocto autobuilder so I can build my own yocto system with it. I have run in to a problem, I can't find a documentation about the autobuilder. Can some one point one out to me? Jun 02 14:39:41 wfailla: there's the readme… and the source code. Jun 02 14:39:50 it's quite sparsely documented Jun 02 14:39:54 but ask and someone might know the answer Jun 02 14:41:01 fwiw pidge is the autobuilder maintainer and she'll probably be around in an hour or so Jun 02 14:41:49 Ok, the task "Running Preamble" fails, because it trys to execute ". ./oe-init-build-env" in the wrong dir. Can I specefi this some where ? Jun 02 14:49:00 wfailla: no, but, it shouldn't be in the wrong dir. can you send me your buildset config file that you're running? Jun 02 14:49:45 wfailla: elizabeth.flanagan@intel.com Jun 02 14:50:51 wfailla: I'll be in in about 90. if you're still around I can step you through some. Jun 02 14:51:02 pidge: hey good to see you online! just a short one - is there already something in place to publish the created rootfs (tar.gz or such) artifacts? Jun 02 14:51:06 gah. Jun 02 15:02:18 YAB: hi all Jun 02 15:04:16 hi Jun 02 15:14:53 YAB: jenkins for the win Jun 02 15:18:10 rburton: now I get a compile time error: ../src/.libs/libdbus-c++-1.so: could not read symbols: File in wrong format Jun 02 15:19:00 its trying to link improperly? Jun 02 15:19:09 ripperD: generally that because its using the host compiler instead of the cross compiler Jun 02 15:19:27 you'll have to read the makefiles and see where it decided to just call gcc directly Jun 02 15:19:42 http://pastebin.com/6ZUMQMJb Jun 02 15:19:47 hmm ok Jun 02 15:20:01 i'm guessing these issues are why it wasn't just in a a layer already Jun 02 15:20:39 or because nobody wanted to use it before Jun 02 15:21:26 oh, fun Jun 02 15:21:38 its attempting to build tooling that it can run a build time Jun 02 15:21:45 and they're using CXX_FOR_BUILD like they should Jun 02 15:21:51 but failing to handle other cases Jun 02 15:24:13 ripperD: you'll need to read tools/Makefile.am and figure out where it decided to use target tools when it should be using native. that makefile sets CXX_FOR_BUILD which is a native compiler, but its then using a cross-libtool. Jun 02 15:31:28 rburton: great, the makefile starts with: # hacky, but ... Jun 02 15:32:05 yeah… Jun 02 15:32:13 actually using CXX_FOR_BUILD isn't hacking, it's the right way Jun 02 15:32:26 but they probably didn't finish the job as it doesn't actually work :) Jun 02 15:33:38 you might need LD_FOR_BUILD or maybe invent LIBTOOL_FOR_BUILD Jun 02 15:43:59 hrm, this looks pretty complicated to my non-developer eyes Jun 02 17:50:43 khem: you around? Jun 02 18:16:02 observation: the ptest suite for valgrind seems to be broken for arm cortex a5, as it seems to implicitly assume arm == armv7 == cortex a8 Jun 02 18:16:46 valgrind itself build fine, BTW - once the inherit ptest is removed Jun 02 18:55:08 So, I sent out a lib/bb/utils.py patch a while back for mkdirhier() to prevent spurious 0777 directories, but it doesn't seem to be merged. I don't see any responses saying there's problems with it, though. RP? Jun 02 19:13:35 seebs: I'm worried about what it potentially does to shared DL_DIR and SSTATE_DIR Jun 02 19:14:05 seebs: I haven't checked into it enough to write a coherent reply to it though :/ Jun 02 19:15:02 Hmm. It's possible that for shared directories, the calls should get a (, 0775) appended. Jun 02 19:15:25 seebs: that is basically my worry Jun 02 19:15:36 Right now, they're just having umask 02 set before they get created, I think. Jun 02 19:16:16 Which implies that they probably want 775. Jun 02 19:16:53 My concern is just that I think anything past 755 should be at least a little considered, or else we might, not-at-all hypothetically, end up with intermediate directories being 777 during the build. Which is potentially risky. Jun 02 19:18:16 seebs: I'm not sure we've ever guaranteed that builds are 100% secure against local exploitation Jun 02 19:18:41 I don't expect a guarantee, but I don't think things should be ending up 777 *accidentally*. Jun 02 19:18:43 seebs: that would imply auditing the temp file creation of every piece of software and is out of out scope Jun 02 19:18:50 seebs: right Jun 02 19:19:19 I agree we should avoid doing bad things if we can. I just don't want to break the real shared use cases we do have Jun 02 20:15:37 JaMa: I've cc'd you on an RFC patch. I'm not sure if its a good idea or not so opinions would be welcome Jun 02 21:47:05 RP: thanks, I've replied there Jun 02 21:48:41 RP: I wonder why I don't see failures from such cases in test-dependencies builds (which are also reusing all deps from sstate and rebuilding just one component), so pruned dependency on pkgconfig-native should probably fail there as well Jun 02 21:52:50 JaMa: I've wondered that too. The dependencies are clearly missing though :/ Jun 02 21:54:48 JaMa: I'd expect you'd already see those warnings in sstate builds of master FWIW Jun 02 22:01:12 maybe it's because there is enough ERRORs to let me ignore WARNINGS :/ Jun 02 22:01:24 I'll check them in next log Jun 02 22:05:25 JaMa: Have you any idea why grub is failing in those builds? It builds fine locally and on the autobuilders Jun 02 22:05:58 JaMa: Its a debugedit failure in do_package and seems to have done it for quite some time. I don't know what configuration may be different to trigger that though Jun 02 22:06:09 It was always failing in that debugedit call Jun 02 22:06:27 which was supposed to be fixed by one of Koen's patches to disable debugedit Jun 02 22:06:43 and I think it was, I didn't investigate why it appeared again in log Jun 02 22:07:05 JaMa: the thing is debugedit makes sense in this case, its a system library/binary Jun 02 22:07:47 JaMa: I've long since noticed it in your logs and its just odd as we never see it elsewhere Jun 02 22:08:46 it's there at least since first report on wiki ( Wed Oct 30 22:22:52 UTC 2013) and it was in couple e-mails before that Jun 02 22:09:12 JaMa: perhaps sometime you could share a tarball of that workdir from a failed build, I can have a look and see if anything jumps out... Jun 02 22:09:30 ok, I'll do that, thanks Jun 02 22:11:42 JaMa: its either going to be something in there, or maybe the debugedit binary itself is behaving oddly on that system, the rpm-native sstate tarball from that build may also help Jun 02 22:12:27 fwiw it's running on Ubuntu 12.04.1 LTS Jun 02 22:23:46 JaMa: right, there is one of those in the YP AB cluster too: https://autobuilder.yoctoproject.org/main/buildslaves/ubuntu1204.osl.yoctoproject.org :/ **** ENDING LOGGING AT Tue Jun 03 02:59:58 2014