**** BEGIN LOGGING AT Mon Nov 03 03:00:00 2014 Nov 03 06:50:00 Gm:) Nov 03 07:57:36 good morning Nov 03 09:47:11 morning all Nov 03 09:47:48 hi bluelightning Nov 03 09:48:28 hello Nov 03 09:49:44 RP: got a new issue after last pull (maybe the gcc poison sysroot patch?) Nov 03 09:49:47 http://pastebin.com/Xdc0rTLC Nov 03 09:51:46 how did libgcc.a disappear from the path? I can set KLIBCLIBGCC but seems highly uncommon Nov 03 09:54:07 hi woglinde, ant_work Nov 03 10:01:06 ant_work: that sysroot patch could cause something like that, yes. Bisection would be the only way to be sture Nov 03 10:01:12 sure **** BEGIN LOGGING AT Mon Nov 03 10:08:03 2014 Nov 03 10:11:06 RP: I'll do. Maybe because it's calling ld directly? Nov 03 10:17:14 ant_work: If you pass the --sysroot option to the compiler/linker, it should work Nov 03 10:21:22 right. quicker than rebuilding gcc ;) Nov 03 10:24:14 on the last round we've considered sysroot for klcc but not for klibc itself Nov 03 11:06:56 hi, how can I export variables from a inherited class? Nov 03 11:07:48 I'm defining a var and then using it within an exported function... but it fails claiming the variable is empty -_- Nov 03 11:08:10 mnemoc: how are you referring to the variable inside the function? Nov 03 11:08:29 ${VAR} or $VAR ? Nov 03 11:09:57 oh. $VAR .... Nov 03 11:10:04 I didn't know it matters Nov 03 11:10:42 I tend to forget bitbake is not sh Nov 03 11:12:21 what's the diff? Nov 03 11:12:55 and what to do with local variables? Nov 03 11:21:14 mnemoc: assuming a shell function, if you use ${VAR}, bitbake will expand the reference when the function is run; if you use $VAR, it's left up to the shell to do the expansion which means the variable itself would also need to be exported Nov 03 11:22:04 if by local you mean inside the function, you'd use $VAR (otherwise the reference might be expanded by bitbake which would probably not be what you want) Nov 03 11:28:24 bluelightning: should I declare those local shell variables as "local"? I don't want to pollute the env Nov 03 11:28:41 or the env is "destroyed" anyway? Nov 03 11:35:38 what's the sense behind AUTOV=`automake --version |head -n 1 |sed "s/.* //;s/\.[0-9]\+$//"` in autotools.bbclass and accessing ${STAGING_DATADIR_NATIVE}/aclocal-$AUTOV later? Nov 03 11:36:09 this will never match because AUTOV is always '1' and no such aclocal-1 directory does exist Nov 03 11:38:00 that sed pattern is clearly wrong Nov 03 11:38:20 it doesn't make sense to take only the last number of the version Nov 03 11:38:50 only "s/.* //" makes sense Nov 03 11:39:43 mnemoc: you wouldn't be polluting the environment, variables set inside the function won't leave the function Nov 03 11:40:15 ah... I see; in master, we have automake-1.14.1 but daisy has automake-1.14 (where I saw these problems) Nov 03 11:40:51 this regexp expects triple version number Nov 03 11:49:10 ensc|w: cut -d. -f1-2 might be simpler than the second sed pattern Nov 03 11:50:39 $ LC_ALL=C automake --version | head -n1 | sed 's/.* \([0-9]\+\.[0-9]\+\).*/\1/' Nov 03 11:50:39 1.14 Nov 03 12:00:52 whole logic is broken; autotools.bbclass uses ${STAGING_DATADIR_NATIVE}/aclocal-$AUTOV but not ${STAGING_DATADIR_NATIVE}/aclocal where things like pkg.m4 are installed Nov 03 13:24:30 what is the purpose of the ACLOCALDIR? afais, it is used by alsa-tools only and prevents using of ${STAGING_DATADIR_NATIVE}/aclocal for all other recipes Nov 03 14:10:17 the ACLOCALDIR stuff breaks 'bitbake -b' because required .m4 files are not copied :( Nov 03 14:15:06 RP ^ Nov 03 14:19:22 bluelightning: hmm :/ Nov 03 14:20:54 We should probably fix it so in the -b case all m4 files are copied Nov 03 15:17:42 RP: or use ${STAGING_DATADIR_NATIVE}/aclocal; there should be no races when using -b Nov 03 15:34:18 ensc|w: true **** ENDING LOGGING AT Tue Nov 04 03:00:00 2014