**** BEGIN LOGGING AT Fri Nov 18 02:59:57 2011 Nov 18 06:48:58 good morning! Nov 18 06:50:23 Have another problem. PTY's are not initialized, so I can't ssh to the pandaboard. I re-create /dev/ptmx and everything works good, but after reboot it happens again... Nov 18 08:10:42 good morning Nov 18 08:13:16 mckoan: morning Nov 18 08:43:33 good morning Nov 18 08:51:41 recalcati: ciao Nov 18 08:53:27 mckoan: ciao ciao Nov 18 09:13:57 mornin Nov 18 09:14:10 Jin^eLD: hi Nov 18 09:37:47 anyone succeeded with building php 5.3.6? Nov 18 09:58:12 hi all Nov 18 10:01:48 pb_: hello Nov 18 10:08:37 hi pb Nov 18 10:46:49 03Richard Purdie  07master * r165a22ddcc 10bitbake.git/lib/bb/siggen.py: (log message trimmed) Nov 18 10:46:49 siggen.py: Fix diffsigs output for filename comparisions Nov 18 10:46:49 When comparing sig files, if the recipe locations had changed, the Nov 18 10:46:49 dependent tasks list would show as changed even if the actual hash Nov 18 10:46:49 had not changed. This updates the code to only compare the base part Nov 18 10:46:49 of the pathnames. Nov 18 10:46:50 It also tweaks some of the output to add newlines to aid comparing Nov 18 10:46:56 03Richard Purdie  07master * r727ca94517 10bitbake.git/lib/bb/siggen.py: (log message trimmed) Nov 18 10:46:56 siggen.py: Include list of variables in hashes Nov 18 10:46:56 Ensure that the list of dependencies is included in the hash Nov 18 10:46:56 as well as their contents Nov 18 10:46:56 Prior to this, adding or removing dependencies with values Nov 18 10:46:57 of "None" would not change the hash, despite diffsigs reporting Nov 18 10:46:57 this difference. Nov 18 11:40:13 hey .. Nov 18 11:40:22 I got an issue with bitbake Nov 18 11:40:28 well, I'm using poky Nov 18 11:40:55 errordeveloper: wrong channel? Nov 18 11:40:58 but I'm just trying to figure whether it's a know issue or something like that Nov 18 11:41:07 well, I wanted to ask in general Nov 18 11:41:39 what may be wrong if bitbake seem to have completed the do_rootfs task Nov 18 11:41:45 but doesn't exit Nov 18 11:42:00 some sort of a locking issue ... Nov 18 11:42:12 anyone experienced this? Nov 18 11:42:59 I think I had it exactly once and was not able to reproduce Nov 18 11:43:41 hm .. I'm able to reproduce it now Nov 18 11:43:52 I use bitbake from poky HEAD Nov 18 11:44:13 I guess it would be in sync with bb HEAD Nov 18 11:44:26 have to check though Nov 18 11:44:40 any hints on how to debug this ? Nov 18 11:45:43 errordeveloper: try reducing BB_NUMBER_THREADS to 1 Nov 18 11:46:08 yeah, I was thinking to try that actually Nov 18 11:46:09 :) Nov 18 11:46:21 right, will do now Nov 18 12:02:35 mckoan: it seems to ignore this option and I can still see 4 python processes (!) Nov 18 12:05:37 errordeveloper: did it do the same thing the second time? Nov 18 12:06:52 bluelightning: sure, it keeps doing it ;( Nov 18 12:07:13 well, being reproducible is good at least Nov 18 12:07:54 :) Nov 18 12:08:28 not too sure 'NOTE: Running task 1889 of 1892 (ID: 8, /opt/devel/tools/oe/poky/meta/recipes-core/images/core-image-minimal.bb, do_rootfs) Nov 18 12:08:44 what would be remaining 3 tasks ? Nov 18 12:10:47 do_build for core-image-minimal at least Nov 18 12:11:22 it's the default task for whatever target is specified Nov 18 12:11:29 but as for the other two I'm not sure Nov 18 12:19:39 ok, I guess that I should start by finding out why the BB_NUMBER_THREADS=1 is being ignored .. Nov 18 12:29:56 hi zecke Nov 18 12:30:45 hi vitus Nov 18 12:38:21 ok, I added a printf line in 'configurator.py' and it doesn't seem to print what I wanted (the number of threds being set) Nov 18 12:38:38 hence the config is chached (?) Nov 18 12:39:55 s/chached/cached/ Nov 18 13:36:15 i'm building a SDK (with bitbake meta-toolchain) and i would like to know if there is a way list the dev packages installed in the sdk Nov 18 13:36:31 to list* Nov 18 13:50:31 hi. is there a way i can get output from a daemon started in angstrom /etc/init.d to go to the console, i can get the output to go to a file with no problem, but if i try > /dev/console 2>&1 or /dev/tty or dev/tty0 , can't get anything to show up on the console. is there something special about oe's syslog.busybox? Nov 18 13:58:22 htns, not sure, but isn't that only a hacky way while boottime? afterwards the tty is "in use" by getty I think... Nov 18 14:02:02 falstaff, ah, i did not know that. i presumed it was always possible for init scripts to log output in some way. i'm now looking at syslog.conf to see if i can find a way to get that output to console the same way kernel output shows up Nov 18 14:04:13 bleh Nov 18 14:13:36 Guys what is the problem here : http://pastebin.com/fkttNW6X Nov 18 14:17:10 ~oe Nov 18 14:17:11 oe is, like, OpenEmbedded (see http://www.openembedded.org ), or "Opportunistic Encryption" (see http://www.wavesec.org ), or an email client which is not to be spoken of. Nov 18 14:18:02 ~topic Nov 18 14:24:23 03Richard Purdie  07master * r658d7daa70 10bitbake.git/lib/bb/parse/parse_py/ (BBHandler.py ConfHandler.py): Nov 18 14:24:23 parse_py: Use absolute paths for FILE Nov 18 14:24:23 Its possible for relative paths to creep into FILE. These confuse the Nov 18 14:24:23 build system no end as its not clear where they might be releative to. Nov 18 14:24:23 This patch ensures we always use resolved absolute paths for FILE Nov 18 14:24:23 so that things behave in a deterministic way. Nov 18 14:24:24 Signed-off-by: Richard Purdie Nov 18 14:31:56 RP__: heh, ouch, I'm surprised we didn't take care of that one years ago :) Nov 18 14:32:21 kergoth: Yes, so am I. Its amazing anything worked... Nov 18 14:32:35 * kergoth nods Nov 18 14:34:43 * Crofton|work curses guile Nov 18 14:34:57 do you know how to fix this error: http://pastebin.com/fkttNW6X ?? Nov 18 14:38:10 try asking in #beagle Nov 18 14:38:36 why? is'nt it concerning with oe? Nov 18 14:39:06 yeah, but the error is in a psecifc recipe closely related to the beagle Nov 18 14:39:41 ok Nov 18 14:42:35 Crofton|work: sadist Nov 18 14:54:14 anybody saw this before? ts_calibrate : selected device is not a touchscreen I understand Nov 18 14:54:32 mckoan: this comes from input api change in the kernel Nov 18 14:55:03 mckoan: but a patch in OE was fixing that Nov 18 14:55:04 ericben: what exactly? is related to a recipe? Nov 18 14:56:59 ericben: I tried investigating with git log but I didn't find anything reporting that Nov 18 14:57:42 mckoan: 1 second please Nov 18 14:57:54 ericben: sure Nov 18 15:01:01 mckoan: http://cgit.openembedded.org/openembedded/tree/recipes/tslib/tslib/0001-relax-EV_VERSION-check-fail-only-if-version-of-runni.patch Nov 18 15:01:16 mckoan: oops sorry that's not the same error Nov 18 15:01:49 mckoan: your message error simply means that the touchscreen driver doesn't report the events tslib is waiting for Nov 18 15:02:01 mckoan: what is your ts controler ? Nov 18 15:04:15 mckoan: ericben: maybe was http://lists.linuxtogo.org/pipermail/openembedded-core/2011-May/002536.html Nov 18 15:04:26 this is in oe-core, though Nov 18 15:05:43 tslib worked until october 2011 Nov 18 15:05:59 not with kdrive, though Nov 18 15:06:00 I'm puzzled, I spent almost 2 days digging it Nov 18 15:06:05 xorg Nov 18 15:06:09 ok Nov 18 15:11:34 mckoan: remember XCALIBRATE was removed with Xorg Server Version 1.10.99.901 (1.11 RC1) Nov 18 15:12:20 I'm pretty sure ts_calibration in oe-classic was broken well before october Nov 18 15:13:44 bbl, bye Nov 18 15:14:13 mckoan: what is your ts controler ? Nov 18 15:21:15 ericben: AT921SAM9263 Nov 18 15:22:14 ok, last time I saw this taht was with a usb ts controler Nov 18 15:22:46 * mckoan is debugging tslib Nov 18 15:22:57 mckoan: stupdid question but did you check that the device you are using is the one of the ts controler ? Nov 18 15:23:23 you can test with evtest to see if it reports the right informations Nov 18 15:23:38 if I replace the tslib files (/usr/lib/ts/*) with the older all works again Nov 18 15:24:17 interesting Nov 18 15:31:04 current tslib shouldn't' have this issue as far as I know Nov 18 15:31:13 do we have a recipe pulling from tslib git yet? Nov 18 15:31:52 https://github.com/kergoth/tslib/commit/412d99d8b92c12545f939972146a38c5074f3dcb Nov 18 15:32:34 * kergoth_ should probably do a 1.1 shortly Nov 18 15:34:25 hmmm Nov 18 15:35:32 if you built it against the same kernel you're running on, this shouldn't be an issue regardless, as far as I know, unless this is a multitouch ts -- see https://github.com/kergoth/tslib/commit/c525c0b5d8eada982c99442454fcf7b8364e10b3 Nov 18 15:35:35 if I use tslib-git I get the error solved by the patch "0001-relax-EV_VERSION-check" Nov 18 15:35:44 that patch is applied in current git Nov 18 15:35:51 so maybe the recipe needs to be bumped to the current srcrev Nov 18 15:36:05 let me unclutter my versions Nov 18 15:42:45 Good morning Nov 18 15:43:14 can someone tell me if there is a log file that capture the output of my bitbake command Nov 18 15:43:45 for example when you build through make there is a log file generated, is there something like that for bitbake? Nov 18 15:44:05 anybody alive? Nov 18 15:44:07 Guest16522: check the ${WORKDIR}/temp of a package Nov 18 15:44:21 Guest16522: unfortunately not Nov 18 15:44:23 Jin thanks for responding Nov 18 15:44:33 same to mckoan Nov 18 15:44:36 mckoan: aren't those the log files in temp in workdir that he is referring to? Nov 18 15:44:53 there is a specific log file for each package Nov 18 15:44:56 I know of that Nov 18 15:45:05 but I started a build last night Nov 18 15:45:07 Jin^eLD: he said a single output of bitbake command Nov 18 15:45:14 went home and came back this morning Nov 18 15:45:17 machine crashed Nov 18 15:45:19 ah, I was not careful enough :P Nov 18 15:45:29 I wanted to know how far the built progressed Nov 18 15:45:44 actually that's afeature I'd ever liked Nov 18 15:45:48 how can I do that Nov 18 15:45:51 can't look into 5000 directories one by one Nov 18 15:46:07 Guest16522: relaunch it and see :-D Nov 18 15:46:45 mckoan Nov 18 15:46:47 bitbake should continue from it was interrupted Nov 18 15:46:49 it takes 4-5 hours Nov 18 15:46:59 it is a huge build based on MontaVista Nov 18 15:47:05 Guest16522: welcome to OE :-D Nov 18 15:47:18 I am sure there must be a log file somewhere Nov 18 15:47:30 for the overall build not per package Nov 18 15:47:40 thanks for your help anyways Nov 18 15:48:41 OE is a huge system and needs time and coffe toot Nov 18 15:49:10 I have no issue with it being big and all Nov 18 15:49:30 but there must be a way to capture the output of the bitbake for a large system Nov 18 15:49:39 if nothing for troubleshooting purposes Nov 18 15:49:57 if one uses the -D option the output of the bitbake simply is overwhelming Nov 18 15:53:52 ericben: sorry, how can I import in my branch the patch you pointed to? http://cgit.openembedded.org/openembedded/tree/recipes/tslib/tslib/0001-relax-EV_VERSION-check-fail-only-if-version-of-runni.patch Nov 18 15:54:38 anyone else can suggest a way for me to capture he output of the bitbake command ( I issued to build my project) Nov 18 15:54:59 sorry if the question is elementary but new to OpenEmbedded Nov 18 15:56:56 Guest16522: you already got a coupe of answers, is not possible except reading each single recipe log Nov 18 15:58:56 oops I guess I endedup in the same channel? Did I ? Nov 18 16:00:39 the screen output is easy.. bitbake 2>&1 | tee Nov 18 16:00:56 but if you want per build logs, you have to agregate them yourselves based on each recipes logs Nov 18 16:01:28 Does anyone know how to caputer the output of the main build (when one issues the bitbake -k world) for example Nov 18 16:01:40 fray I had a build started last night Nov 18 16:01:42 and went home Nov 18 16:01:50 this morning I came back to work Nov 18 16:01:56 machine crashed Nov 18 16:02:16 I want to know how far the build progressed? Was it successful or not? Nov 18 16:02:20 you have to capture the log when you start the build -- or as mentioned before simply look though the log directories for each recipe Nov 18 16:02:32 re-run bitbake.. it'll continue where it needs to -- or do nothing if everything this done Nov 18 16:02:33 I know there is a log file for each recipe Nov 18 16:02:45 but I have like 5000 packages Nov 18 16:03:02 ya, and it takes bitbake about 30 seconds to decide if they're done or not.. Nov 18 16:03:15 ok thanks Nov 18 16:03:37 in the command you gave me Nov 18 16:03:49 the is the name of the log file right? Nov 18 16:03:57 yes Nov 18 16:04:12 Thank you Sir Nov 18 16:04:12 I regularly run bitbake as: bitbake core-image-minimal 2>&1 | tee log Nov 18 16:04:22 then I can look at "log" if I have questions about what ran Nov 18 16:04:35 not familiar with tee command right now reading the man page Nov 18 16:04:40 it'd really be nice if we did that automatically some how Nov 18 16:04:50 the real difficulty would be determining a good place to put the log Nov 18 16:04:51 sorry if my question is elemantary a Nov 18 16:04:56 lacking TMPDIR at that point Nov 18 16:05:03 heh Nov 18 16:05:20 IMHO the ui log doesn't belong in tmpdir Nov 18 16:05:38 I assumed the output of the command that fray gave Nov 18 16:05:49 will go to your current directoy where the command is issued Nov 18 16:05:59 (and I've heard lots of complaints by folks new to oe/bitbake that they don't like the "tmp" name.. because there is stuff in there that is not "temporary".. such as the deploy directory.... Nov 18 16:06:05 mckoan: I would say git cherry-pick 390e8cd69ee11bcc8a10ea3d887a386eab2579cb http://cgit.openembedded.org/openembedded/diff/?id=390e8cd69ee11bcc8a10ea3d887a386eab2579cb Nov 18 16:06:08 or one can put the absolute path to the log file Nov 18 16:06:09 yes Nov 18 16:06:09 true, but I'd hate if it cluttered up my $PWD or something too Nov 18 16:06:16 fray: have you seen koen's "ideal layout" email? Nov 18 16:06:23 no, I've not seen it Nov 18 16:06:29 something like /home/user/ for example Nov 18 16:08:43 it breaks it up quite nicely -- of course, it doesn't actually work due to sstate and all, but he puts all the layers and bitbake in source/, tmpdir in build/tmp-whatever, sstate in build/sstate-cache, and then there's an output/images and output/packages dirs for DEPLOY_DIR bits Nov 18 16:09:30 ok, I do remember some talk about that before.. for the most part I think it's reasonable.. but there are things I don't like about it Nov 18 16:09:47 I don't have any issue at all with the current layout of the bitbake/oe groups of sources.. Nov 18 16:10:26 but I would have a "sources" (a.k.a. downloads) directory in the top level directory.. as well as an sstate-cache -- or something that holds cached data.. Nov 18 16:11:00 under the project directory a.k.a build directory.. I would have the normal conf.. and then at the high level have the deploy and sysroot directories.. Nov 18 16:11:11 everything else can then be under tmp.. Nov 18 16:11:16 I've occasionally wondered about moving bits outside of the build dir. its nice that we're self contained, but certain things are common. download cache for example.. Nov 18 16:11:18 kergoth, do you have a link to that mail handy? was that in oe dev ml? Nov 18 16:11:24 ericben: yes I must have used a wtong commit IS to searh it Nov 18 16:11:30 s/IS/ID Nov 18 16:11:43 I just don't see the downloads, sstate-cache, sysroot or deploy items as "temporary".. and the first two aren't even really project based.. Nov 18 16:11:46 Have u guys seen the way MontaVista did the file strucutres of its distribution? Nov 18 16:11:53 ericben: BTW the commit 390e8cd69ee11bcc8a10ea3d887a386eab2579cb is already active Nov 18 16:11:57 I know it's different, but I haven't seen it Nov 18 16:12:10 they put everything under /tmp Nov 18 16:12:13 which I don't like Nov 18 16:12:16 ericben: already pushed Wed Jan 12 Nov 18 16:12:21 that seems a bit odd.. Nov 18 16:12:36 I made some changes to the *.bb and patch files Nov 18 16:12:38 build crashed Nov 18 16:12:39 I could see an argument for the download cache going into something under ~ or even /var/cache or something, really Nov 18 16:12:55 by default, i mean Nov 18 16:12:55 had to resort to rm -rf /tmp Nov 18 16:12:58 after some tests I saw that using tslib-1.0 i get selected device is not a touchscreen I understand Nov 18 16:12:59 everything was gone Nov 18 16:13:08 can't do that for my customers because many are on corporate machiens and they can't muck with anything outside of their user permissions.. Nov 18 16:13:13 and with tslib-git I get tslib: Selected device uses a different version of the event protocol than tslib was compiled for Nov 18 16:13:18 also ~ is usually on a shared resource and -very- tiny Nov 18 16:13:18 yeah thats pretty common Nov 18 16:13:38 tslib doesnt' work in any case Nov 18 16:13:41 mckoan: well, its telling you the problem.. it was built against one set of headers with one version of the event interface and that doesn't matter your current kernel Nov 18 16:13:52 match, that is Nov 18 16:14:29 (I would also have multiple sstate-cache's and downloads directories.. so they can be shipped with each layer... but I'm not sure that is possible iwth the current configuration) Nov 18 16:14:52 I've thought about that too. per layer output would be nice for deployment Nov 18 16:15:01 you can't just break up SSTATE_DIR though due to the context the state code runs in Nov 18 16:15:02 the layers and such are "RO" directories for me.. the user wants to make changes they do it in their own local layer.. Nov 18 16:15:13 would have to analyze the sig info files after the fact Nov 18 16:15:29 we actually do something similar in our (non bitbake) system.. we simply iterate through the layers for the cached information.. Nov 18 16:15:38 * kergoth_ nods Nov 18 16:15:40 first found wins in the cache Nov 18 16:16:08 when we write out the cache files, we do it within the projects settings and have an export function that can move the cache back to their appropriate layers... Nov 18 16:16:18 (again not bitbake so it's not exactly 1:1) Nov 18 16:16:24 ah, thats definitely quite similar to what we'd have to do here though Nov 18 16:16:48 ...the first directory scanned BTW is the last layer in the search order... Nov 18 16:16:59 the last layer being the user's local development layer Nov 18 16:17:24 i.e.: oe-core, meta-oe, , ..., Nov 18 16:17:52 mckoan: maybe that broke here http://cgit.openembedded.org/openembedded/commit/?id=b9103c3e4fc289093550b17b07ae6575fe05664d when you upgraded LINUX_LIBC_HEADERS_VERSION Nov 18 16:18:12 sstate-cache, downloads, etc are all search in reverse order.. Nov 18 16:21:20 ericben: your're right thanks, BTW I don't understand why using tslib-git [which has the new if (version < EV_VERSION)] doesn't work properly Nov 18 16:21:21 kergoth, You meant that one? http://lists.linuxtogo.org/pipermail/openembedded-core/2011-August/007388.html Nov 18 16:21:55 that was it, yeah. might not be ideal, but i do think discussions should get going about things like that Nov 18 16:21:56 the asy solution would be go back to LINUX_LIBC_HEADERS_VERSION ?= "2.6.31" but I'd like to understand Nov 18 16:23:14 mckoan: what is your kernel version ? Nov 18 16:23:17 if you were built against a newer kernel than you're running, then its using a version of the event interface that your kernel may well not support, hence the check, and hence the error Nov 18 16:23:25 afaik, anyway Nov 18 16:23:32 ericben: 2.6.28.10 Nov 18 16:23:33 I don't really pay much attention to ts stuff anymore Nov 18 16:23:48 mckoan: in fact your message explains that the event structure is not the right one if I understand well Nov 18 16:24:04 ericben, kergoth: aha! Nov 18 16:24:26 and that patch just makes it so it checks that the kernel's version is older than what it was built against rather than exactly equal Nov 18 16:24:37 or whatever, or vice versa, whatever Nov 18 16:24:41 there's still a case where it'll fail.. Nov 18 16:25:16 but I didn't write the code, just took over maintenance Nov 18 16:26:24 ericben, kergoth: now is clear, thank you very much Nov 18 16:27:13 its certainly possible that the check isn't really needed, but it guards against a possible event api change that could break it in inexplicable ways Nov 18 16:27:21 better to fail outright than that happen Nov 18 16:27:25 * kergoth_ shrugs Nov 18 16:46:59 what's the qa_staging's purpose? Nov 18 16:49:58 verify what was built is reasonable Nov 18 16:50:11 things like I was building for ARM and got a PPC binary would fail Nov 18 16:51:07 fray: thanks. Nov 18 16:51:29 keep failing on ti arago's /join #arago Nov 18 16:51:48 external-toolchain-csl-1.0-r11 Nov 18 17:04:07 fray: http://pastebin.com/c7C7Mu5m Nov 18 17:05:28 I see at least two issues.. Nov 18 17:05:51 the first I think is a warning, that says that some of the libraries are being packaged and don't match the soname it was expecting.. those may be harmless warnings for glibc Nov 18 17:06:35 i have two 10.04 64bit ubuntu, one built fine, one keeps throwing out this error. Nov 18 17:06:35 the second, that IS an error in that GNU_HASH support is not part of libgcc_s.so -- this may cause failures on current versions of oe-core because various things are looking for GNU_HASH entries in the ELF files, and not the older SYSV style hashs.. Nov 18 17:06:43 i compared both installation to a package list level Nov 18 17:07:00 in otherwords -- you have a mismatch between this package and what the system was expecting.. likely the compiler isn't capable of doing what it should Nov 18 17:07:28 like 6 and 8 are what is causing the failure.. and it's internal the binaries themselves.. Nov 18 17:07:39 i tried to move away from the build-well machine to a faster one, but keep getting this error Nov 18 17:07:52 this has nothing to do with the build system.. it's the toolchain you have Nov 18 17:07:55 the same compiler is used Nov 18 17:08:35 perhaps this QA check moved froma warning to an error more recently then the last time you built on your previous machine? Nov 18 17:08:43 the error is reasonable.. you need GNU_HASH Nov 18 17:10:02 this is the check, from meta/classes/insane.bbclass: Nov 18 17:10:03 gnu_hash = "--hash-style=gnu" in d.getVar('LDFLAGS', True) Nov 18 17:10:03 if not gnu_hash: Nov 18 17:10:03 gnu_hash = "--hash-style=both" in d.getVar('LDFLAGS', True) Nov 18 17:10:03 if not gnu_hash: Nov 18 17:10:03 return Nov 18 17:10:28 if your LDFLAGS say --hash-style=gnu or both.. then it expects, and verifies, all binaries on the system have GNU_HASH style.. the ones being reported do not.. Nov 18 17:10:45 checking here... Nov 18 17:10:51 check your platforms LDFLAGS and change the hash style away from "gnu".. Nov 18 17:11:13 "sysv" is the older style Nov 18 17:11:45 ./bitbake.conf:TARGET_LINK_HASH_STYLE ?= "${@['-Wl,--hash-style=gnu',''][d.getVar('LINKER_HASH_STYLE', True) != 'gnu']}" Nov 18 17:11:55 so it looks like it's "LINKER_HASH_STYLE" that you need to find.. Nov 18 17:12:21 looking at bitbake.conf further.. it defaults to "gnu".. only mips default to sysv Nov 18 17:12:35 but in the end, the compiler (external CS compiler) is not mathcing your system configuration.. Nov 18 17:12:47 set LINKER_HASH_STYLE = "sysv" in your conf/local.conf and it'll likely go away Nov 18 17:13:41 so we should use gnu nowadays? Nov 18 17:14:48 ya.. GNU_HASH is more efficient Nov 18 17:15:09 the compiler and linker need to be setup to do this.. as well as the base configurations.. the cs toolchain you have is not setup that way Nov 18 17:16:38 ...a couple year old explanation of GNU_HASH... Nov 18 17:16:39 http://blogs.oracle.com/ali/entry/gnu_hash_elf_sections Nov 18 17:17:10 my eye sees that sort order and bloom filters help improve performance over sysv.. Nov 18 17:17:24 quicker rejects.. and better validation for matches Nov 18 17:17:48 fray: thanks! Nov 18 17:18:06 will set LINKER_HASH_STYLE = "sysv" in local.conf for now Nov 18 17:20:00 have a nice weekend Nov 18 17:28:13 I've added an enhancement request to the (yocto) bugtracking system, bug 1773, to better document the built-in QA process Nov 18 17:30:28 regarding hash style be aware that gnu hash does not work for mips due to fundamental incompatibilities Nov 18 17:30:45 so if you are using a mips based bsp dont use gnu hash Nov 18 17:30:56 yup.. Nov 18 17:31:13 khem, I know you've been busy.. any chance to look at the prelink & mips issues from a month or so ago? Nov 18 17:31:24 fray: no :& Nov 18 17:31:31 no worries.. Nov 18 17:31:33 been away from internet for 3 week Nov 18 17:31:41 but I have it in my list Nov 18 17:31:41 (that isn't a bad thing) Nov 18 17:32:07 I know. I needed it Nov 18 17:32:31 right now I have lot of unfurl not done with work emails yet :) Nov 18 17:33:13 I suspect once someone with better overall toolchain knowledge (on mips) then me sees the issue, they'll understand it and be able to explain whats wrong (likely with prelink) Nov 18 17:44:51 fray: that still did not help after changing to sysv Nov 18 17:45:03 same QA message? Nov 18 17:45:09 yes Nov 18 17:45:20 I'm not sure.. I've not played with it much.. Nov 18 17:45:32 the only other thing you can do is demote it from being an error to a warning.. Nov 18 17:45:39 let me see if i can remember how to do that Nov 18 17:47:53 Hmm.. at least in oe-core the GNU_HASH check should be a warning and not an error.. Hmm Nov 18 17:49:22 check your configuration.. do you have WARN_QA or ERROR_QA set anywhere? Nov 18 17:50:38 the strange thing is that, it built fine on a different machine with same ubuntu/pkgs Nov 18 17:50:41 let me check Nov 18 17:52:04 fray: not found anywhere Nov 18 17:52:12 then I'm not sure.. sorry.. Nov 18 17:52:23 fray: thanks for the help! Nov 18 17:52:25 my meta/classes/insane.bbclass has the "ldflags" check in WARN_QA.. Nov 18 17:52:34 will stick with my old slow but reliable dell for now Nov 18 17:52:36 and the ldflags check includes the check for GNU_HASH Nov 18 17:52:37 compaq sucks Nov 18 17:53:49 xxiao: what is the problem you are seeing Nov 18 17:55:11 khem, he's getting a QA erorr: that the GNU_HASH isn't present in a binary.. Nov 18 17:55:22 khem: i build ti's arago on one ubuntu 10.04 64bit for a long while, moved that code to a faster compaq with the same software installed, now bitbake failed on GNU_HASH or something Nov 18 17:55:26 I suggested changing the hash style to sysv... but he said that didnt work Nov 18 17:55:43 and then I was looking at changing the check from an error to a warning.. but from what I see (in oe-core) it should already be a warning and not error Nov 18 17:55:50 that machine meanwhile locked twice on aptitude-upgrade, so i feel it's a bad one Nov 18 17:56:14 i built yocto, angstrom,etc just fine on the nwe machine though Nov 18 17:56:15 ok this means linker options are not honored Nov 18 17:56:30 he's using a prebuilt code sourcery toolchain Nov 18 17:56:35 so ya, it's not using GNU_HASH Nov 18 17:56:38 for TI's arago i had to use the golden-forever 2009q1 release Nov 18 17:56:55 xxiao: you can add TARGET_CC_ARCH += " ${LDFLAGS}" to the concerned recipe Nov 18 17:57:07 khem: tried that did not help Nov 18 17:57:08 that should then link it properly Nov 18 17:57:32 ah prebuilt one Nov 18 17:58:03 ya.. so changing it to use sysv style should "work" and also fix the QA issue Nov 18 17:58:46 I guess they should use gnu hash style in 2009 Nov 18 17:59:22 you can try to pass hash style option in both CFLAGS and LDFLAGS Nov 18 17:59:25 to be sure Nov 18 20:49:01 does anyone know if there is a race when two recipes fetch from the same source? Nov 18 20:54:37 just reading the last GA, "paypal: €141.28 (2 donations of €100 minus fees)" Nov 18 20:54:54 €59 of fees? :D Nov 18 20:55:56 it's including some Merkozy taxes already? :p Nov 18 21:12:07 msm: for reading what race could there be Nov 18 21:13:28 khem: i meant fetching =) Nov 18 21:13:41 two recipes are trying to 'git clone' Nov 18 21:15:37 msm: hmm cloning into same git tree I think should not Nov 18 21:16:31 ynezz: eu has this VAT Nov 18 21:17:02 and its now in India too. I paid like 20% to govt when I bought a burger at Mcdonald Nov 18 21:17:33 and everything that went into making that burger would have paid VAT too Nov 18 21:17:51 its a wicked tax Nov 18 21:28:14 ynezz: 59 sounds a bit high, maybe also USD -> EUR conversion... 2x100 USD Nov 18 21:28:52 ynezz: and then paypal's ~3% percent on the 147... you would be at around 142 Nov 18 21:29:48 ynezz, dobule check with florian Nov 18 21:29:59 maybe there is a typo Nov 18 21:30:38 although these international paypal transfers are annoying Nov 18 21:30:51 khem: it was just going really slow… i think it would have been OK thoough Nov 18 22:07:30 does anyone know about forcing gcc to look in a relative path for libgcc Nov 18 22:07:46 for example if I copy a x86 sysroot OUT of the OE build environment elsewhere… and invoke Nov 18 22:08:05 $ ~/x86_64-linux/usr/libexec/ppce500v2-fsl-linux-gnuspe/gcc/powerpc-fsl-linux-gnuspe/4.6.1/gcc -print-libgcc-file-name Nov 18 22:08:05 /local/home/mattsm/git/poky/build_p1020rdb_release/tmp/sysroots/p1020rdb/usr/lib/powerpc-fsl-linux-gnuspe/4.6.1/libgcc.a Nov 18 22:08:25 its still point at the old libgcc - not the libgcc in the sysroot gcc is running from **** ENDING LOGGING AT Sat Nov 19 02:59:56 2011