**** BEGIN LOGGING AT Wed Sep 28 02:59:56 2011 Sep 28 09:02:53 hi, what's the correct way to pass CFLAGS to configure? Sep 28 09:03:00 I tried many ways for instance: Sep 28 09:03:18 EXTRA_OECONF_append = ' CFLAGS="${CFLAGS}"' Sep 28 09:03:37 and I get configure errors about my CFLAGS for instance: Sep 28 09:03:55 configure: error: unrecognized option: `-pipe' Sep 28 09:04:12 because it does CFLAGS=-O2 -pipe I think Sep 28 09:04:15 not sure tough Sep 28 09:22:38 never mind I'll work arround with CC += Sep 28 09:23:08 since the underlying autotool configure.ac or something like that seem broken somehow.... Sep 28 10:34:47 GNUtoo|work: did you try just CFLAGS += "xxx" Sep 28 10:35:09 GNUtoo|work: autotools is usually pretty good about picking up our cflags Sep 28 11:02:19 is there a devtools group I can add to the core-image-minimal build which will include all the tools and servers required for debugging eclipse? Sep 28 11:02:34 *debugging in eclipse Sep 28 11:03:11 I have added tcf-agent and gdbserver however I get an error that libstdc++ is required by gbdserver - does this mean the dependancy chain is broken for gdb? Sep 28 11:07:00 http://pastebin.com/u7bDrMUk Sep 28 11:08:02 or is that error showing an issue with the standard helloworld code? Sep 28 11:11:35 Snafflehog: since you're using eclipse remotely which I have no experience with I can't answer most of your questions, but I would suggest that core-image-minimal is not a good image to be using for development Sep 28 11:11:43 it has no packaging system for one Sep 28 11:12:34 what image would you suggest, as I am looking for a basic image which I can build up to have exactally what I wish on it? Sep 28 11:13:36 I'm not interested in the sato stuff, but would just like a base system that I can work with Sep 28 11:23:06 well, during development, core-image-base should be OK Sep 28 11:23:14 at least then you can use IMAGE_FEATURES Sep 28 11:23:42 you can still base on core-image-minimal when you've finished doing development Sep 28 11:28:58 ok, thats very helpful, I didn't realise the core-image was indeed so basic Sep 28 11:30:53 Snafflehog: AIUI, core-image-minimal is designed to be almost as cut-down as possible; but that means a few things that might be useful for development is not there Sep 28 11:31:02 s/is not/are not/ Sep 28 12:00:50 RP__, ok I'll retry Sep 28 12:02:21 didn't work Sep 28 12:05:09 I think it's only passed with export Sep 28 12:05:37 GNUtoo|work: maybe TARGET_CFLAGS? I can't remember which name its passed in under Sep 28 12:05:52 GNUtoo|work: autotools does pick it up somehow... Sep 28 12:07:02 it did, I'll look if it still does Sep 28 12:07:08 I'll look in autotools.bbclass Sep 28 12:08:29 gnutls fails to build for me with the error: | make[4]: Entering directory `/mnt/yocto/poky/qemuarm-toolchain/tmp/work/armv5te-poky-linux-gnueabi/gnutls-2.12.5-r2.0/gnutls-2.12.5/lib/po' Sep 28 12:08:29 | *** error: gettext infrastructure mismatch: using a Makefile.in.in from gettext version 0.17 but the autoconf macros are from gettext version 0.18 Sep 28 12:09:07 this is a simple versioning mismatch that needs to be updated right? Sep 28 12:10:07 it's not in CONFIGUREOPTS , I'll look in base.bbclass then Sep 28 12:11:02 and oe_runmake only does that: ${MAKE} ${EXTRA_OEMAKE} Sep 28 14:23:49 Snafflehog: those versions should match (gettext and gettext-native) Sep 28 14:24:22 GNUtoo|work: but the variable is exported and looked for by autotools as far as I recall Sep 28 14:30:42 ok Sep 28 14:31:50 RP__ so my host distributions gettext is too new for the yocto gettext - is that right? Sep 28 14:45:47 Snafflehog: it shouldn't be using your host distribution's gettext Sep 28 14:47:01 ok, so does poky build gettext and gettext-native (I was under the impression that by gettext-native you meant host distribution, but rather its gettext_x86?) Sep 28 14:47:42 Snafflehog: Its a gettext package compiled to run on the system you're building on (this is what *-native packages are) Sep 28 14:49:02 ah ok, so could the arm/x86_64 gettext package become out of sync Sep 28 15:18:26 I used -c clean and -c cleansstate on gnutls and it seems to have ditched an old version which was hanging around, will update when(if) the build finishes sucessfully Sep 28 16:00:13 my TERMCMD spawning is not working Sep 28 16:03:34 msm: which terminal(s) do you have installed? Sep 28 16:06:34 XTERM Sep 28 16:06:41 its not finding the DISPLAY env variable Sep 28 16:06:43 and failing out Sep 28 16:06:47 but its working Sep 28 16:14:18 msm: that's strange... would you be able to file a bug for that? Sep 28 16:15:31 ill look a little closer then file a bug Sep 28 16:15:46 are you see anything the same? Sep 28 16:16:06 err, it should be easy to test on edison with a -c menuconfig or something Sep 28 16:17:13 when I did a recent bugfix I did test devshell with xterm, and that worked Sep 28 16:17:27 I have not tested menuconfig though I would expect others to have done so at some point recently Sep 28 16:19:47 well i hit the error on a patch recovery Sep 28 16:19:52 let me see if it's just on patches first Sep 28 21:04:06 sgw: hello Sep 28 21:04:41 ant__: Evening to you Sep 28 21:05:10 I see you (somehow) touched as least person the tzcode/tzdata recipes Sep 28 21:05:18 wuh.. Sep 28 21:05:27 s/least/last/ Sep 28 21:05:50 now, there are some improvements to take from meta-oe Sep 28 21:05:52 What's up? I may have updated it last yet Sep 28 21:06:20 You are welcome to submit the changes if you would like. Sep 28 21:06:34 is there a specific maintainer? Sep 28 21:07:51 ant__: We can take patches from out side of the maintainers. Sep 28 21:08:06 ok, great Sep 28 21:08:45 then, there are much heavier changes for the newer udev recipe...here I hesitate Sep 28 21:08:51 And if you would like to help with maintainership of any recipes, it's alway welcome! Sep 28 21:09:07 nah, is just for 'reducing the delta' Sep 28 21:09:21 those recipes should be in oe-core only Sep 28 21:10:01 I try to purge them out of meta-oe but RP now thinks to bitrot old recipes there :p Sep 28 21:10:01 agreed Sep 28 21:10:06 hehh Sep 28 21:10:59 finally, our JaMa is cooking some new xorg-xserver work in the -contrib branches Sep 28 21:11:24 then X will hopefully be in one single place as well Sep 28 21:12:05 I like that idea! Sep 28 21:12:17 I hope he'll send a pull request soon Sep 28 21:31:34 sgw: anybody in the group interested in early boot/initramfs? Sep 28 21:33:29 ant__: there are people interested in this of course, we are looking to create a small image with fast boot of course, this is in the same vein as initramfs Sep 28 21:33:58 I see Sep 28 21:34:15 Are you also looking into that? Sep 28 21:34:37 I somehow maintain klibc and kexecboot in OE Sep 28 21:34:54 so yes Sep 28 21:35:27 you should talk with dvhart he is one of the kernel guys. Sep 28 21:39:14 I see, thx Sep 28 21:45:52 incandescant: how does hob parse the available image types? im adding some IMAGE_TYPES in another class and hob is not picking them up Sep 28 21:54:02 msm: they need to be added somewhere which is parsed at hob launch, i.e. image_types.bbclass is added to INHERIT in the hob conf files by the wrapper script Sep 28 21:59:53 incandescant: adding INHERIT to hob-pre.conf seems to fix the issue, will this work to generate these images? Sep 28 22:00:46 if the image creation commands are correct it should Sep 28 22:00:52 k Sep 28 22:01:02 thanks Sep 28 22:02:24 np **** ENDING LOGGING AT Thu Sep 29 02:59:56 2011