**** BEGIN LOGGING AT Fri Aug 29 02:59:58 2014 **** BEGIN LOGGING AT Fri Aug 29 05:50:55 2014 Aug 29 09:31:36 hello, phone call :/ Aug 29 09:32:38 RP: I have seen strange things with gcc-cross and this is really not my fielde of expertise Aug 29 09:32:59 neverthless I think there might be an issue Aug 29 09:33:37 khem says it's ok, though... Aug 29 09:34:02 the problem: I build for armv4 and armv5te Aug 29 09:35:06 it seems to me gcc-cross is taking the first machine-sysroot built Aug 29 09:37:29 so i.e. if I build poodle before collie the --with-gxx-include-dir , --with-sysroot, --with-build-sysroot are pointing to poodle Aug 29 09:38:21 if I then build klibc binaries for collie these contain (bx lr) Aug 29 09:38:33 If I first build collie it is ok... Aug 29 09:40:48 RP: is it right that the EXTRA_OECONF_PATHS are so based on the first STAGING_DIR_TARGET built? Aug 29 09:44:20 http://lists.openembedded.org/pipermail/openembedded-devel/2014-August/097877.html Aug 29 09:50:11 ant_work: that is correct Aug 29 09:50:26 ant_work: we always pass the correct sysroot into the compiler through commandline args Aug 29 09:50:50 ant_work: There has been discussion about poisoning the default value which I keep meaning to do Aug 29 09:52:22 RP: so I have to extend the klcc commandline with TOOLCHAIN_OPTIONS = " --sysroot=${STAGING_DIR_TARGET}" ? Aug 29 09:52:46 to override the default Aug 29 09:52:59 ant_work: I'd have thought it should already be set to the right value in the various commands like CC Aug 29 09:53:18 ant_work: but if klcc's commandline doesn't do this, then yes Aug 29 09:53:41 atm it is just Aug 29 09:53:43 export CC_armv4_linux-gnueabi = "${TARGET_PREFIX}klcc -march=armv4 Aug 29 09:53:43 -mthumb-interwork" Aug 29 09:54:17 and fwiw export CPP = "${CC} -E" Aug 29 09:54:40 (in klibc.bbclass) Aug 29 09:55:43 so basically it was building by pure luck since we have a single gcc-cross-arm ... Aug 29 09:57:07 ant_work: well, this is what you get to manually putting these options together :/ Aug 29 09:57:15 ant_work: you need to add the --sysroot one Aug 29 10:02:21 hm... ok, so like in bitbake.conf I have to add TOOLCHAIN_OPTIONS Aug 29 10:04:48 I'll try, thanks **** BEGIN LOGGING AT Fri Aug 29 11:05:05 2014 **** BEGIN LOGGING AT Fri Aug 29 11:19:08 2014 Aug 29 12:48:39 Is there a way to clean all versions of a recipe? Say you built multiple versions of a recipe doing a clean will only clean the latest version. But is there a command to go back and clean all the older versions of a recipe also? Aug 29 13:09:55 khem: are you looking at the fsl-arm build failure using 2.20 glibc? Aug 29 16:54:41 otavio: not right now, but I have sample fix for other drivers which needs to be applied to that failure see http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/eglibc-to-glibc-2.20&id=10609ab00efb8bc5334992f5736b5cf8f1264654 Aug 29 17:22:41 base_contains is being replaced by bb.utils.contains . but there isnt bb.utils.conditional, so base_conditional has to stay, right? Aug 29 18:47:05 Is there a .bb recipe for libnfc ? In general, is there a place one can search for recipes ? Aug 29 18:48:28 http://layers.openembedded.org/ Aug 29 18:48:33 same place you search for layers and machines Aug 29 18:48:47 http://layers.openembedded.org/layerindex/branch/master/recipes/?q=nfc Aug 29 18:49:58 kergoth, thank you Aug 29 22:00:12 good evening fine gentlesirs and madams Aug 29 22:01:05 I would like to inquire as the proper method of ensuring a bb recipe (in a dir under recipes) gets included and built Aug 29 22:01:32 must I simply drop in the recipe, or include it as a dependency somewhere? Aug 29 22:01:41 that depends on what you're trying to accomplish Aug 29 22:01:48 if all you want to do is build it, you can run bitbake and call it a day Aug 29 22:02:00 if you want it added to a filesystem image for your target, thats something else entirely Aug 29 22:02:05 yes, the latter Aug 29 22:02:29 CORE_IMAGE_EXTRA_INSTALL += "packagename" in local.conf will add it to all the core images Aug 29 22:02:35 or you can create your own image in your own layer Aug 29 22:04:30 Quick question. In OE Daisy, the binutils symlinks changed from being generated at build time to using alternatives. This resulted in the symlinks having absolute rather than relative paths (e.g. objcopy points to /usr/bin/x86_64-nilrt-linux-objcopy rather than x86_64-nilrt-linux-objcopy). Aug 29 22:04:48 thank you kergoth Aug 29 22:04:49 Is there a way for us to change these symlinks to be generated as relative again? Aug 29 22:05:01 what symlinks? Aug 29 22:05:02 you are both a gentle-person and a scholar in the fine arts of OE Aug 29 22:05:04 context would be useful here Aug 29 22:05:08 sirnarwhal: np Aug 29 22:05:37 the ones generated under /usr/bin for the binutils recipe Aug 29 22:06:14 you mean update-alternatives links? Aug 29 22:06:21 yes Aug 29 22:07:03 hmm, not sure Aug 29 22:07:24 See 7f8eedaa86c64ec67ece84cf636b7001b95db686 in poky Aug 29 22:07:54 Just as a test, in meta/recipes-devtools/binutils/binutils.inc, line 60, I changed the ALTERNATIVE_TARGET to just prefix+alt, and it didnt' seem to change what was generated. Aug 29 22:07:59 not sure if there's a safe way to revert that behavior without sacrificing compatibility (aside: we need to fix the chkconfig alternatives to allow relative paths) Aug 29 22:08:07 that's correct, it won't Aug 29 22:08:15 see the commit i just mentioned Aug 29 22:08:21 the links are made absolute by update-alternatives.bbclass Aug 29 22:08:21 ok, taking a look, thanks Aug 29 22:12:30 OK, that explains it. Aug 29 22:12:50 we should improve that, it'd be nice to have fewer absolute symlinks in the rootfs in general Aug 29 22:14:35 I understand why that's necessary for compatibility reasons. Would there be a middle ground where some things could have a relative path, like adding a flag to update-alternatives? Aug 29 22:17:14 (We're looking for a way to deal with this that's potentially upstreamable and less of a hack than "revert it locally") Aug 29 22:19:21 I think the best bet would be to fix all the update-alternatives implementations to handle relative links properly, then we wouldn't need that bit in the bbclass to force it to absolute Aug 29 22:19:47 iirc cworth's shell update-alternatives implementation from opkg-tools supports them, but debian and chkconfig's do not Aug 29 22:23:47 Cool -- thanks so much! I understand the issue a lot better now. Aug 29 22:26:10 most folks use cworth's update-alternatives, but not all. at mentor we're using chkconfig's, since it's written in C rather than shell Aug 29 22:26:14 np Aug 29 23:08:34 otavio: I just sent the patch for meta-fsl-arm for glibc-2.20 issue Aug 29 23:08:47 you are on cc Aug 29 23:08:59 I am not subscribe to meta-fsl-arm ml **** ENDING LOGGING AT Sat Aug 30 02:59:59 2014