**** BEGIN LOGGING AT Fri Sep 19 03:00:00 2014 Sep 19 07:07:14 good morning Sep 19 07:10:24 (UMT) Sep 19 07:32:16 exq Sep 19 08:31:40 sup Sep 19 08:50:11 morning all Sep 19 08:59:53 hi bluelightning Sep 19 09:05:17 hi mckoan Sep 19 11:01:32 ll Sep 19 13:23:23 gees, im looking at the build log, for my minimal image, and i see it including recipes for automake, ..sqlite. bison, flex ... etc .. lots of stuff Sep 19 13:23:42 my first question would be, is it really included into the image, and if so why. why would i need all this in minimal Sep 19 13:24:43 b00^wk: no, those won't be included in the image, those are build-time dependencies needed in order to build the things that are though Sep 19 13:24:52 ah ok Sep 19 13:26:03 I'm investigating 'playing' with Yocto Build Appliance. The smallest 'minimal' image, it seems it can make, is 64MB. with a click of a button that is. i haven't edited anything. I did inidcate i want 32MB total, but that's probably not possible in premade config Sep 19 13:36:50 I'm building a package for a native SDK, but I'm getting a problem with the linker trying to look for libc, pthreads etc, in the default directory for SDK installation (a directory that does not exist yet!). Is this familiar to anyone? Sep 19 13:37:55 It should look for stuff under builddir/tmp/sysroots/..../lib/libc.so.6, but instead it looks under /opt/..../lib/libc.so.6 Sep 19 13:49:39 wto: that sounds like the relocation script did not run, which it should have when you installed the SDK... Sep 19 13:57:48 bluelightning: well this is during build, I have no SDK to install. Sep 19 13:58:08 that is, I am trying to produce one, but the linker is behaving as if there is one already. Sep 19 13:59:29 hmm ok... I haven't had to troubleshoot such an issue I'm afraid, perhaps someone else has Sep 19 14:01:15 It's probably an issue with the recipe, since I can build most other packages for that SDK, but I'm thinking it might be a common issue, that there is a pattern or something. Sep 19 14:45:27 Hi all. Can anybody explain me why when i set several packages in IMAGE_INSTALL i dont have its in image (but can find its in deploy/rpm)? Sep 19 14:47:55 interima: where are you setting IMAGE_INSTALL? Sep 19 14:50:48 bluelightning: in my local conf i add some packages to IMAGE_INSTALL_append Sep 19 14:51:24 hmm, that should work then... Sep 19 14:52:51 i add fftw (and find it in rpm) not in image, but i also add pulseaudio-server and it was added to image Sep 19 14:54:36 bluelightning: http://pastebin.com/qBzM1gfi Sep 19 14:57:31 also i find fftw lib in tmp/sysroots/wandboard-quad/usr/lib. i generate toolchain then but no libfftw there.(for my task i simply copy this lib to toolchain folder). Sep 19 15:24:37 wto: the compiler options are probably going missing, specifically the --sysroot= option Sep 19 15:24:53 wto: or its using the wrong compiler Sep 19 15:25:33 interima: how are you generating the toolchain? Sep 19 15:31:50 interima: that IMAGE_INSTALL line should work, but to be honest I would suggest you add your own image recipe for this rather than having such a long addition in local.conf Sep 19 15:32:27 RP: hi Sep 19 15:32:31 while you're surviving to th enetspolits, about --sysroot... Sep 19 15:32:57 RP: woulds you suggest to use TOOLCHAIN_OPTIONS instead of explicit --sysroot=${STAGING_DIR_TARGET} ? Sep 19 15:35:14 ant_work: using the toolchain options makes it more generic I think **** BEGIN LOGGING AT Fri Sep 19 15:42:01 2014 Sep 19 15:42:07 ant_work: yes, I was hinting what the problem might be, not how to pass it in Sep 19 15:46:36 RP: I have seen T_O is prone to mangling Sep 19 15:47:59 RP: http://lists.openembedded.org/pipermail/openembedded-devel/2014-September/098127.html Sep 19 15:49:32 RP: if both you and khem suggest to use TOOLCHAIN_OPTIONS I'll be glad to send a patch v2 Sep 19 15:52:41 ant_work: I don't understand what you mean by mangling? Sep 19 15:52:58 unsetting Sep 19 15:53:37 ant_work: well, think about this for a minute. If you're building something to run on the build system, does setting target toolchain options make sense? Sep 19 15:53:49 ant_work: that is why native/cross/cross-canadian change these Sep 19 15:53:57 ant_work: I do suggest using it FWIW Sep 19 15:54:26 ok, thanks Sep 19 15:54:56 I was thinking at the following scenary: 'inherit cross klibc' Sep 19 15:55:52 ant_work: it really needs to get the correct value from the environment at runtime Sep 19 15:56:59 atm we only build recipes for target, nothing to do with native and cross Sep 19 15:57:17 so I can safely use TOOLCHAIN_OPTIONS Sep 19 15:57:29 ant_work: so why it is inheriting cross? :) Sep 19 15:57:33 it was Sep 19 15:57:44 you helped me making a crosscript Sep 19 15:57:50 right Sep 19 15:57:54 and it doesn't any more? Sep 19 15:58:11 it's ok, just gcc encodes the sysroot of the first build Sep 19 15:58:28 ant_work: separate issue as we've discussed Sep 19 15:58:39 yes, the patch is fixing that Sep 19 15:59:10 but I agree now, using T_C in a class is better Sep 19 16:00:14 I'll send a revised patch, thanks again Sep 19 16:34:22 hi, why do I not get libfl.so into the SDK if my package depends on flex and I put it into the (R)DEPENDS lines. Sep 19 16:34:25 ?* Sep 19 16:53:47 zeddii, does thrift make sense to you? Sep 19 17:11:29 bluelightning: are you still around? Sep 19 17:11:43 sort of Sep 19 17:12:36 bluelightning: do you know why flex does not end up in the SDK? Sep 19 17:12:50 no, I don't Sep 19 17:12:56 cannot find -lfl is what I am getting. I am not sure why. Sep 19 17:13:06 if I build the software in Yocto, then it is fine, but not with the SDK. Sep 19 17:13:31 but it is very unlikely to be an issue with Yocto; more likely an issue with my setup. Sep 19 17:13:55 but I am not sure what to look for in my setup. Sep 19 17:15:35 if yourapp is in the image, you do -c populate_sdk on the image, then yourapp-dev should depend on flex-dev and that should depend on other flex packages Sep 19 17:15:45 that's how it should work, at any rate Sep 19 17:18:35 bluelightning: http://paste.kde.org/pnvw6cngb -> I have these four items that I depend on. Sep 19 17:18:38 flex is the last one. Sep 19 17:18:53 it is not any more granular than that so that it is just in the recipe right there. Sep 19 17:18:59 yeah so that's DEPENDS Sep 19 17:19:08 I also have RDEPENDS the same way. Sep 19 17:19:24 does the package "flex" actually contain libfl.so? Sep 19 17:19:32 no idea :) Sep 19 17:19:35 re RDEPENDS Sep 19 17:19:39 well, have a look ;) Sep 19 17:21:17 I seem to have: ./tmp/sysroots/foo/usr/lib/libfl.a, but I cannot find any .so. Sep 19 17:21:44 I am afraid that that is all. Sep 19 17:23:13 rm_work? Sep 19 17:24:32 bbl Sep 19 17:25:00 yeah, rm_work. Sep 19 17:25:43 this makes me curious how it works even inside Yocto... Sep 19 17:39:15 RP: thoughts on perhaps making cleansstate taint something, to avoid pulling from a mirror in the subsequent built? cleansstate is most often used when someoen wants to rebuild from scratch, but with mirrors involved.. alternatively, maybe it's just a question of improving documentation for that case, instructing folks to 1) -c clean, 2) -C fetch or so Sep 19 17:39:21 s/built/build/ Sep 19 18:44:15 huh, that's odd, I don't see a recipe for https://github.com/Herzult/SimplePHPEasyPlus in oe-core? Sep 19 18:44:21 Surely I'm not the only person who needs it. Sep 19 21:59:48 kergoth: It is something which has bothered me for a while. As you mention, there is a workaround and documenting that would at least help. We could make cleansstate use the same taint as -f does I guess Sep 19 22:00:13 thats what i was mulling over. not sure if its too much magic or exceeds the intended semantics of the task, though Sep 19 22:00:15 * kergoth shrugs Sep 19 22:00:20 its definitely a source of confusion Sep 19 22:00:27 (the current behavior, that is) Sep 19 22:20:59 kergoth: It does exceed it a bit but it might be more what the user wants Sep 19 22:21:20 kergoth: At least now any taints show up as warnings so the user is much more aware than they ever used to be Sep 19 22:21:28 that's a good point Sep 20 00:01:56 This is my first time on the Yocto IRC, I hope this is the right place for this. Has anyone experienced build failures when building util-linux (bitbake util-linux) or gettext (bitbake gettext)? I am showing "undefined reference to 'mbrtowc'" and "undefined reference to 'wcwidth'". I first saw these errors when trying to build core-image-minimal-initramfs. **** ENDING LOGGING AT Sat Sep 20 03:00:00 2014