**** BEGIN LOGGING AT Wed Dec 21 02:59:56 2011 Dec 21 03:43:42 I am working for 1t91sam9263 board. When I compile "bitbake virtual/kernel" It gives the error: /linux-2.6.30/tools/perf: No such file or directory. Dec 21 03:45:54 tool directory is only present from kernel 2.31 onwards, but there is only patch available for at91sam9263 linux 2.30. Pls help me what to do? Dec 21 05:40:01 When I build Sdk i got the ERROR: runstrip: ''arm-angstrom-linux-gnueabi-strip' strip command failed. pls help me! Dec 21 07:05:28 When I build Sdk i got the ERROR: runstrip: ''arm-angstrom-linux-gnueabi-strip'  strip command failed. pls help me! Dec 21 07:51:41 When I Compile the SDK, bitbake meta-toolchain-qte I got the error: Dec 21 07:51:42 ERROR: runstrip: ''arm-angstrom-linux-gnueabi-strip' --remove-section=.comment --remove-section=.note '/media/Working/angstrom/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/qt4-embedded-4.7.4-r39.5/package/usr/bin/rcc'' strip command failed Dec 21 08:24:51 good morning Dec 21 08:41:27 Hi all Dec 21 08:59:43 pb_: ping Dec 21 09:00:50 hi zecke Dec 21 09:03:15 When packaging Qt libraries, I got the ERROR: QA run found fatal errors. Please consider fixing them. Dec 21 09:03:40 and? Dec 21 09:04:22 and ERROR: Function 'do_package_qa' failed NOTE: package qt4-embedded-4.7.4-r39.5: task do_package: Failed Dec 21 09:04:34 and? Dec 21 09:04:49 pastebin it Dec 21 09:10:18 I have put the error in pastebin Dec 21 09:11:04 pb_: I'm using rm_old_work from meta-micro and found small issue with -dbg packages, fixed by http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=0d4c17de1ba7343d82bb10c311754e29d573c485 Dec 21 09:21:04 ERROR: QA Issue: Architecture did not match (40 to 3) on /work/armv5te-angstrom-linux-gnueabi/qt4-embedded-4.7.4-r39.5/packages-split/qt4-embedded-tools/usr/bin/rcc | ERROR: QA Issue: Architecture did not match (40 to 3) on /work/armv5te-angstrom-linux-gnueabi/qt4-embedded-4.7.4-r39.5/packages-split/qt4-embedded-tools/usr/bin/moc | ERROR: QA Issue: Architecture did not match (40 to 3) on /work/armv5te-angstrom-linux-gnueabi/qt4-embedded Dec 21 09:21:54 I thing 3 bin file problem to do_pack failed Dec 21 09:22:17 so, what should i do? Dec 21 09:27:21 write to the oe-core ml Dec 21 09:27:35 bluelightning or ericben may answer Dec 21 09:35:00 Thanks Dec 21 11:11:01 * mckoan has booked the flight for FOSDEM 2012 (Brussels, Belgium) Dec 21 11:23:38 oh, hm, fosdem. what dates is it this time? Dec 21 11:28:47 pretty early this tie Dec 21 11:28:48 time Dec 21 11:28:51 4th and 5th Dec 21 11:29:04 ah Dec 21 11:29:06 (of february) Dec 21 11:29:31 I am going to california at the end of jan. not sure I will be able to manage fosdem that soon afterwards. Dec 21 11:30:25 oh, actually, there's 2 weeks between them. looks like we are flying back from the usa on jan 20. Dec 21 11:30:49 so that might be manageable, perhaps. I'll talk to Ruth and see what she thinks. Dec 21 11:34:33 ok. keep me posted. i didn't book anything yet either. Dec 21 11:45:15 pb_: what do you think about that patch? maybe it should be fixed in package.bbclass instead Dec 21 11:50:08 um, which patch are we talking about? Dec 21 11:54:32 0:05:15 < JaMa|Wrk> pb_: I'm using rm_old_work from meta-micro and found small issue with -dbg packages, fixed by http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=0d4c17de1ba7343d82bb10c311754e29d573c485 Dec 21 11:55:09 10:05:15 Dec 21 11:55:35 oh, right Dec 21 11:55:44 I think that should be fixed in package.bbclass. I don't think using WORKDIR for that is sensible. Dec 21 11:56:12 ok, thanks Dec 21 11:57:17 if it wants the basename of the traditional WORKDIR then it should be using ${PF} Dec 21 12:01:21 pb_: agreed, I didn't look into bbclasses yet, but maybe sourcepkg.bbclass needs similar fix too if it's using WORKDIR Dec 21 12:51:59 rp ping Dec 21 12:52:27 how do we prevent automake from adding rpath Dec 21 13:40:04 hm I wonder if we can rewrite libtool ltmain, so we have a -rpath replace it with -rpath-link to the sysroot dir and -rpath targetdir Dec 21 13:40:13 ant_work: does klibc still build for you with current linux-libc-headers-3.1, here it fails to find asm/bitsperlong.h because thats in include/asm/generated Dec 21 13:43:11 hi JaMa|Wrk Dec 21 13:44:25 I've built last week just fine, can't remember headers version, though Dec 21 13:44:37 (I'm testing klibc_2.0 btw) Dec 21 13:53:58 Hi Dec 21 14:18:43 hi Dec 21 14:19:08 does anyone here meet the c++ header problem when building from scratch ? Dec 21 14:19:46 ericben: iirc there's a thread about it in oe-core ml Dec 21 14:20:01 ericben: it seems khem is the one looking at it Dec 21 14:20:07 otavio: I know I started the thread Dec 21 14:20:11 otavio lol Dec 21 14:20:12 or one before Dec 21 14:20:17 ericben only ulf so far Dec 21 14:20:32 but my problem is that I reproduce that very easily on different hosts Dec 21 14:20:32 ulf? Dec 21 14:20:47 I only discovered the wrong iclude searchpath when not using --sysroot Dec 21 14:20:49 ericben: and he does not? Dec 21 14:21:21 so either we have something wrong in our setup Dec 21 14:21:29 but I hoped they were coupled somehow Dec 21 14:21:40 what I find surprising is that no one else meet this problem Dec 21 14:21:54 exepct Ulf of course Dec 21 14:22:02 we all have sucky machines Dec 21 14:22:13 cannt make more than 8 threads Dec 21 14:22:16 well I now reproduce it with BBTHREAD=2 Dec 21 14:22:16 or 4 Dec 21 14:22:22 :-( Dec 21 14:22:25 uhm what? Dec 21 14:22:29 how this? Dec 21 14:22:36 with khem patches? Dec 21 14:22:49 headers are not there? Dec 21 14:22:50 yes, (with or without) Dec 21 14:24:36 humm Dec 21 14:25:24 headers are hereand headers are in sysroots/machine-name//usr/include/c++/ Dec 21 14:26:00 in fact simply doing from scratch a bitbake of a qtdemo image leads to the problem Dec 21 14:26:03 okay Dec 21 14:26:11 than the search path is wrong Dec 21 14:26:23 can you run devshell Dec 21 14:26:34 ericben: are you using the qt patches? Dec 21 14:26:36 on the failing package to check the search path ? Dec 21 14:26:41 otavio: which qt patches ? Dec 21 14:26:47 ericben: bluelightning ones Dec 21 14:26:51 ericben: for 4.8 test Dec 21 14:27:07 otavio: no, not on my standard builds Dec 21 14:27:23 and use the compile command with --verbose and -Wl,-verbose Dec 21 14:27:35 that will show use Dec 21 14:27:44 where g++ is searching for headers Dec 21 14:28:02 woglinde: I'll test on next failure (I just fired a new build) Dec 21 14:28:08 okay Dec 21 14:29:11 woglinde: that's a good idea thanks for it Dec 21 14:30:19 what remain strange is why the build succeed in some case and fail in others Dec 21 14:31:24 hm yeah I am puzzeld too Dec 21 14:31:33 do you always start from scratch? Dec 21 14:33:50 woglinde: I try to do regulare build from scratch as in the end, that's what the customer are doing when we deliver a BSP Dec 21 14:34:29 and often that show bugs which are hidden when doing incremental builds Dec 21 14:35:01 I'll tru to remove meta-oe & meta-angstrom to see if I reproduce the problem Dec 21 14:35:47 doing regular build from scratch is a good idea to find hidden problems Dec 21 14:36:12 except in the present case where not many peoples meet this problem Dec 21 14:36:49 I also have a patch which adds python to gdb but doesn't manage to get feedback for it Dec 21 14:36:57 I have weekly from scratch builds and daily tmp removal builds Dec 21 14:37:00 at the moment I have issues with: fakeroot, base-passwd, busybox doing build from scratch Dec 21 14:37:29 seems oe-classic to oe-core switch reduced the community Dec 21 14:38:03 no Dec 21 14:38:05 ericben: yes indeed, and also interest on oe Dec 21 14:38:05 hm Dec 21 14:38:12 partly Dec 21 14:38:17 we got 10 people from intel Dec 21 14:38:27 so until now I like the tradeoff Dec 21 14:39:38 well have intel focused people doens't help for other archs Dec 21 14:40:30 but the other importan parteds we didnt care this much before Dec 21 14:40:32 like license Dec 21 14:40:37 regular updates Dec 21 14:40:42 of most used packages Dec 21 14:41:17 yes there are indeed improvements (I didn't say the contrary) Dec 21 14:41:32 but I find the community far reduced than before Dec 21 14:41:43 that's maybe a false impression Dec 21 14:42:13 did we have this big community before? Dec 21 14:42:15 I think that's probably an accurate impression. Dec 21 14:42:19 but just look at the trafic on the lists and the small diversity of posters Dec 21 14:42:28 most were employees Dec 21 14:42:35 to what extent it's a bad thing is possibly another question. Dec 21 14:42:49 even if before the community was not huge Dec 21 14:43:04 community was mickeyl, jama, ant, paulepanther and me Dec 21 14:43:14 of course questions often bring other questions ;-) Dec 21 14:43:26 jama is using oe-core Dec 21 14:43:30 ant is using oe-core Dec 21 14:43:47 Hmm. I think a heck of a lot of people are still confused by the transition. I don't think there's even an official post on the site telling people we are transitioning, is there? Beyond that, development is now largely split across layers, which means we don't see a single pile of commits anymore (though cbrake's mail helps) Dec 21 14:43:48 * kergoth shrugs Dec 21 14:44:21 yeah, indeed. the smartphone folks are off doing their own thing in their own layer for example, which is fine. Dec 21 14:44:33 yeah Dec 21 14:44:49 if people tell me what they want I'll write something Dec 21 14:44:57 I'm not quite sure what became of openslug, for example. did that project just die, or are they still on oe-classic, or are they using something else entirely? Dec 21 14:45:04 or are they using a layer and we just don't hear about it? Dec 21 14:48:42 no idea Dec 21 14:48:55 good question. looks like there's a slugos layer, but don't see anything for openslug Dec 21 14:49:20 aside: LayerIndex should probably be linked a bit more prominently given how important it is for figuring out what content went where Dec 21 14:49:21 heh Dec 21 14:49:25 khem did make a slugos layer (and an nslu2 machine one) but I'm not sure anybody ever did anything with them Dec 21 14:49:32 I think we lost people because of linaro and ubuntu arm afford Dec 21 14:50:03 hm hm Dec 21 14:50:09 kergoth: yes... so where should we link it from? Dec 21 14:50:16 the rpath fixes in libtool are not perfect Dec 21 14:50:33 good question. would think either the front page, or some sort of page documenting the transition which doesn't exist :) Dec 21 14:50:52 * kergoth shrugs, generally avoids the wiki, it's a giant pile of disorganized tidbits, sadly Dec 21 14:50:56 kergoth: well there is the OE-core page I wrote which talks about the transition Dec 21 14:51:05 kergoth: though again that is not linked from the main page Dec 21 14:51:11 * kergoth nods, true, good point Dec 21 14:51:28 kergoth hm yes wiki needs strong rules Dec 21 14:51:28 maybe a link under news to the oe core page would be a step in the right direction? Dec 21 14:51:30 even so that page probably needs more stuff in it though Dec 21 14:51:56 yes we definitely should put up a short news item Dec 21 14:52:43 If I've held back in the past it's only because I felt I didn't have the authority to modify the front page Dec 21 14:53:18 I think you're not the only one who feels that way, that's probably part of the problem :\ Dec 21 14:53:52 perhaps, yes Dec 21 14:58:11 bl do it as with other stuff Dec 21 14:58:15 make a post to the ml Dec 21 14:58:21 if nobody complains Dec 21 14:58:23 do it Dec 21 15:00:41 btw, just a quick reminder that nominations for the tsc election will close in 9 hours. if anybody else wishes to stand then they should say so soonest. Dec 21 15:48:40 ericben: btw I fixed webkit being disabled Dec 21 15:50:08 it's a little bit of a hack, but I'm not sure the configure script expects QMAKE_CXX to include a reference to another variable; as far as I can tell the reference was not being expanded correctly in 4.7.4 either Dec 21 15:50:46 I've re-pushed the paule/qt-4.8.0-test contrib branch Dec 21 15:52:03 * JaMa|Wrk re-merges Dec 21 15:53:18 bluelightning: ok that's very strange Dec 21 15:59:04 btw bluelightning I think c96db08915a554fb5e4bb2c360b919c8392b32c6 introduced a bug as now we package moc rcc lrelease and uic in qt-tools ... but that's the host versions which are packaged leading to a QA error Dec 21 15:59:47 ericben: for the full story see http://bugzilla.pokylinux.org/show_bug.cgi?id=1856 Dec 21 16:00:05 just saw your mail Dec 21 16:00:22 Can someone remove or reset my user at wiki? Dec 21 16:00:31 recovery password seems not working for me Dec 21 16:01:47 bluelightning: this patch should not have been comitted http://patches.openembedded.org/patch/16397/ your questions were not answered Dec 21 16:02:14 ericben: the problem is I tested it and it was fine :/ Dec 21 16:02:26 strange Dec 21 16:02:41 yes, sometimes they are correct arch and other times not Dec 21 16:03:04 how is that possible, that's similar to the c++ header : sometimes that works somethimes that doesn't work Dec 21 16:03:16 ericben: if you can reproduce it maybe you could give me some info about your setup and help me to do the same Dec 21 16:03:32 bluelightning: I just have it in direct live on one of my builds Dec 21 16:03:45 ericben: which machine? Dec 21 16:03:54 bluelightning: that's and armv5 machine Dec 21 16:05:01 in qt4-embedded-tools, under packages-split : [ebenard@e6520eb qt4-embedded-tools]$ file usr/bin/uic Dec 21 16:05:04 usr/bin/uic: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not stripped Dec 21 16:05:38 uhm yes Dec 21 16:05:44 in fact since a few days most of my build always fail either on c++ headers ... and now on qt QA Dec 21 16:05:52 tjere was someone else here with the problem Dec 21 16:06:09 yes that's hte bug bluelightning mentionned a few lines ago Dec 21 16:06:22 these random things are quite anoying Dec 21 16:06:42 well let's see if we can get to the bottom of this one Dec 21 16:07:07 bluelightning: I'm you man if you have some ideas of where to look for the problem Dec 21 16:07:21 if you want the logs I can tbz2 temp and send it tou you Dec 21 16:09:41 ericben: yes please Dec 21 16:10:47 ericben: if you could also send me the Makefile from src/tools and src/tools/uic that would be great Dec 21 16:12:38 bluelightning: that's in you mailbox (or will be in a few seconds) Dec 21 16:13:10 ericben: w.r.t. gxx headers issue is it reproducible always or just works second time around Dec 21 16:13:34 khem: always reproducible Dec 21 16:13:44 thats cool Dec 21 16:13:50 which package should I bake to get it Dec 21 16:14:02 once it has failed, the only solution is to clear build change BB_THREAD and fire a new build Dec 21 16:14:13 ah sorry I understand what you mean now Dec 21 16:14:23 no it's not always reproducilbe when we build from scratch Dec 21 16:14:54 ericben: got it thx Dec 21 16:15:04 once it has failed launching again bitbake doesn't help Dec 21 16:15:23 does it end up with same error again and again ? Dec 21 16:15:29 khem: if some log for toolchain package are of interest I can send them to you Dec 21 16:15:45 khem: when it fails yes : always one c++ header whihc is not found Dec 21 16:15:49 ericben: I will be interested to access the build space Dec 21 16:16:04 since it does not seems to be a problem with compiler Dec 21 16:16:35 when it says cxx header not found the header is there in target sysroot includes Dec 21 16:16:36 right Dec 21 16:16:47 khem: something like that : mkdgifft.cpp:64:16: fatal error: list: No such file or directory Dec 21 16:17:11 ericben: ok and do u have /usr/include/c++/list staged ? Dec 21 16:18:06 and the header is in sysroot : http://pastebin.com/eSGQkrWm Dec 21 16:18:09 and what is the gcc commandline for this failing case ? Dec 21 16:18:31 yes it is there I see Dec 21 16:18:43 brb in 10 mins time to drop kids to school Dec 21 16:19:01 khem: commande line http://pastebin.com/Yn1ghL4E Dec 21 16:28:19 er Dec 21 16:28:23 oops Dec 21 16:40:42 ericben: is that with gcc 4.5 or 4.6 Dec 21 16:41:11 ericben: can you paste arm-angstrom-linux-gnueabi-g++ -v output somewhere Dec 21 16:42:44 khem: http://pastebin.com/WiYnAmRc Dec 21 16:42:53 4.5.4 Dec 21 16:44:14 hmmm ok is list in this dir /home/ebenard/OECORE/setup-scripts/build/tmp-angstrom_2010_x_eukrea-cpuimx51-eglibc/sysroots/eukrea-cpuimx51/usr/include/c++ Dec 21 16:45:08 khem: it is : http://pastebin.com/55P1Qejd Dec 21 16:45:30 khem: each time I've met the problem, the header was present Dec 21 16:47:07 ok I think I might be knowing what the problem is Dec 21 16:48:00 khem: cool that would save me a few builds and will save the planet by not overusing my cpu ;-) Dec 21 16:49:20 ericben: I will cook up a litte patch and expect that you will test it Dec 21 16:49:57 khem: of course on several machines Dec 21 16:53:25 someone has recipes for firefox/? Dec 21 16:53:45 otavio: not here. oe-classic has some Dec 21 16:53:47 for old versions Dec 21 16:54:23 ericben: yes Dec 21 16:54:32 ericben: I'd like to get an updated one Dec 21 17:16:19 ericben: I have hatched a patch and send to mailing list give it a shot Dec 21 17:16:28 http://patchwork.openembedded.org/patch/17379/ Dec 21 17:17:06 and let me know if it helps Dec 21 17:18:10 khem: ok a build just failed with fatal error: new: No such file or directory. I'm applying your patch and launching it again Dec 21 17:18:30 btw do we have a patchwork script in oe-core ? Dec 21 17:18:38 yes please do. I have bumped the pr so it should rebuild gcc Dec 21 17:19:21 khem: I'm starting with a clean build or do you prefe r I try with the failed tmp ? Dec 21 17:19:23 ericben: when you were replying to the gxx headers thread on ml did you always mean 4.5 or 4.6 Dec 21 17:21:51 khem: it doesn't apply Dec 21 17:22:14 ooops it's for meta-oe sorry Dec 21 17:23:35 khem: 4.5 this is locked by angstrom default versions Dec 21 17:24:23 ericben: hmm I see, so we were not on same page there I and RP were thinking you were using gcc 4.6 Dec 21 17:24:37 since the patches I did earlier were only for 4.6 Dec 21 17:24:53 I am now worried about what JaMa|Off saw Dec 21 17:24:57 that can be a problem Dec 21 17:25:25 when you use sstate and different machine but same toolchain Dec 21 17:25:35 eg. beagleboard and beaglebone Dec 21 17:26:01 then he saw some issues with gcc-runtime thats worrying Dec 21 17:26:11 anyway time to drive Dec 21 17:26:39 khem problem is the same Dec 21 17:27:04 woglinde: what do u mean Dec 21 17:28:03 g++ headers Dec 21 17:33:50 khem: I also have a problem with different machines and meta-toolchain : http://lists.linuxtogo.org/pipermail/openembedded-core/2011-December/014480.html Dec 21 17:34:17 khem: and someone reported something similar today : http://lists.linuxtogo.org/pipermail/openembedded-core/2011-December/014793.html Dec 21 17:36:12 khem: seems the packages which was failing is now building fine Dec 21 17:36:44 khem: once this build finish I'll fire an otherone with cleaned tmp and let you know Dec 21 17:36:54 khem: thanks Dec 21 17:52:06 What can lead to this error? satisfy_dependencies_for: Cannot satisfy the following dependencies ... Dec 21 17:52:28 wow, this lenovo thinkpad protection is rather expensive. Dec 21 17:52:30 * pb_ reels Dec 21 17:52:49 fcooper: sounds like you have some unsatisfied dependencies. what exactly is the "..."? Dec 21 17:53:23 could be stale binaries that need rebuilding, or could be a missing DEPENDS somewhere, or could be other things. Dec 21 17:54:30 pb_: http://pastebin.com/CinFG3sR Dec 21 17:55:37 pb_:  matrix-gui-multimedia-demos and matrix-gui-display-control are recipes I just created and when building those recipes individually I have no issue. Dec 21 17:57:05 hi fcooper : did you test the patch concerning qtcreator & gdb ? Dec 21 17:59:19 do those packages exist in tmp/deploy/*/ipk? Dec 21 17:59:37 it sounds as though maybe your recipes generated no output. Dec 21 18:15:09 ericben: humm are you integrating the sdk with qtcreator? Dec 21 18:15:22 otavio: yes Dec 21 18:15:34 ericben: how is it going? Dec 21 18:15:53 otavio: with the gdb patch I sent even remote debug works Dec 21 18:16:02 AWESOME Dec 21 18:16:14 ericben: with qemu or real boards? Dec 21 18:16:16 btw if you can test that and ack it Dec 21 18:16:37 ericben: I'm fighting with udev right now Dec 21 18:16:40 otavio:beging hardware designer I'm only working with real boards ;-) Dec 21 18:17:03 ericben: updating it in oe-core Dec 21 18:17:48 I just havea problem left with the latest qtcreator Dec 21 18:17:59 but with the previous ones it's working fine Dec 21 18:25:40 pb_: You were right. Dec 21 18:28:33 ericben: What problems are you having with the latest qt creator? I haven't had an issue yet and it fixed one or two annoying issues that the previous version of qt had. Dec 21 18:29:18 ericben: but you don't build qtcreator on the sdk itself, do you? Dec 21 18:29:29 otavio: no using binary one fro nokia Dec 21 18:29:38 ericben: ah right Dec 21 18:29:57 ericben: that might be nice as it would allow for putting fixes on it Dec 21 18:30:26 fcooper: iirc with the latest one it doesn't execute the script I need to upload the binary on the target Dec 21 18:30:36 even if the checkbox is checked Dec 21 18:35:54 ericben: That is one thing I haven't gotten a chance to look into yet. The other thing I wanted to look into is adding the debug libs for Qt. There is alot of info that the Gdb helper doesn't show that the debug libs will show that will make debugging Qt applications alot easier. Dec 21 18:36:52 ,true Dec 21 19:15:36 ericben: good so it seems it works a bit for you Dec 21 19:16:26 re khem Dec 21 19:17:25 ericben: re. SDK it seems its reusing the native tools which isnt so bad but then SDKs are not standalone anymore Dec 21 19:17:30 woglinde: hello Dec 21 19:17:56 SDK needs some love but also a faster machine to rebuild toolchain :) Dec 21 19:19:07 khem: in a few weeks I may be able to give remote access to one of my build box with an i7 if needed Dec 21 19:19:17 and quite lot of ram Dec 21 19:19:34 ericben: will be fine Dec 21 19:19:57 although network delays might be annoying across continents Dec 21 19:20:19 while you only build & test on this machine that will be fine as we have a good network here Dec 21 19:20:32 the only proiblem is the upload speed (1Mbps) Dec 21 19:20:54 and as you are on when I'm off, there won't be bandith conflicts ;-) Dec 21 19:21:49 will email you when that's ready Dec 21 20:09:05 hi khem Dec 21 20:10:25 I tried all incantations possible and I don't succeed at building a toolchain with the SHR distribution Dec 21 20:10:50 currently eglibc-initial fails with: Dec 21 20:10:51 | ../nptl/sysdeps/unix/sysv/linux/bits/local_lim.h:39:26: fatal error: linux/limits.h: No such file or directory Dec 21 20:11:07 should I bitbake linux-libc-headers first? Dec 21 21:13:43 ericben: ok cool Dec 21 21:13:51 GNUtoo: is it with oe-core ? Dec 21 21:14:04 GNUtoo: explain in detail what you are trying to do Dec 21 21:18:38 khem, hi Dec 21 21:18:45 yes with shr-core more exactly Dec 21 21:19:02 basically I do a bitbake shr-lite-image and toolchain failed Dec 21 21:19:05 so I cleaned it Dec 21 21:19:07 like that: Dec 21 21:19:37 http://www.pastie.org/private/mdzevw2v56ue9c7vwpeooq Dec 21 21:19:45 and re-did a bitbake shr-lite-image Dec 21 21:19:52 but then it failed again Dec 21 21:19:57 so I cleaned stuff separately Dec 21 21:20:02 and re-did an shr-image Dec 21 21:20:06 but it fiailed again Dec 21 21:39:02 khem, what should I do now? Dec 21 23:03:50 khem: your patch (17379 in pw) solves the c++ header problem I met (third sucessful build), thanks very much Dec 21 23:04:48 cool Dec 21 23:15:43 woglinde: I was to stupid to see I'm using 4.5 when last patch made by khem was for 4.6 ... Dec 21 23:16:03 no prop Dec 21 23:20:42 time to sleep now, will test all that tomorrow on the hardware bye Dec 21 23:20:56 nite Dec 21 23:51:44 GNUtoo: ok Dec 21 23:52:02 GNUtoo: what was the error Dec 21 23:52:21 is it using oe-core + meta-oe Dec 21 23:52:28 and what version of gcc is it using Dec 21 23:57:40 good nite **** ENDING LOGGING AT Thu Dec 22 02:59:57 2011