**** BEGIN LOGGING AT Tue Jan 03 02:59:57 2012 Jan 03 10:49:07 hi all Jan 03 12:22:28 morning all Jan 03 13:15:17 hi Jan 03 16:38:03 zeddii: just sent you an email regarding a build failure, have you seen that one? Jan 03 16:48:39 RP__: email for both the coreimage changes and meta-yocto changes sent Jan 03 17:11:49 * halstead waves hello. Jan 03 17:12:22 halstead: Happy New Year Jan 03 17:12:39 Happy new year sgw. Jan 03 17:22:53 halstead: hi! HNY :) Jan 03 17:24:12 HNY to you too RP__ . Jan 03 18:13:18 * bluelightning -> home Jan 03 18:25:01 RP__: please hold off on pulling the POKY -> COREIMAGE until later, the AutoBuilder needs more work Jan 03 18:25:22 RP__: Can you pull the meta-yocto changes to master? Jan 03 18:46:57 hm, is the poky mailman list configured to not send a copy if the destination email is detected in the To/CC? Jan 03 18:47:49 walters, I can check on that for you. Jan 03 18:59:52 walters, Filter out duplicate messages to list members (if possible) is enabled on the poky mailing list. Jan 03 19:00:23 =( Jan 03 19:00:48 10 years of contributing to free software, 10 years of hating mailing lists Jan 03 19:01:46 Maybe we can find a work around. What's the issue with suppressing duplicates? Jan 03 19:02:27 it's good for people who don't have filters set up, they don't get two copies of the mail Jan 03 19:02:56 if you do have filters, it's not easy to put the mail into the right folder Jan 03 19:03:19 gmail gets this right with labels, but... Jan 03 19:03:24 That makes sense. Jan 03 19:04:26 anyways i'm sure the mail admin toggled that because they wanted it that way (it's not the default AIUI), so rather than talking more here i'll just try to figure out some workaround Jan 03 19:16:54 hm, so why the heck does flex hardcode the path to m4? Jan 03 19:17:25 I believe that can be overridden.. if it can't, then it's a bug in our version of flex.. Jan 03 19:17:37 (it should check the M4 environment variable) Jan 03 19:17:53 fray: Yeah M4 is accepted by flex. iirc. Jan 03 19:18:13 it looks to me like the current bitbake recipie works for native but not when installed into the target Jan 03 19:18:58 but there's nothing host-dependent about m4 is there? seems to me like upstream is just being dumb here Jan 03 19:24:36 oh i see, if running on solaris or some crap we need to know where we found GNU m4 Jan 03 19:27:08 does it find the m4 itself on target or not ? Jan 03 19:28:27 khem, no, the generated binary has the full staging path Jan 03 19:29:01 i tried to skip yocto for this and build flex with my native os build tool, but it only builds from git, and flex self-build-depends =/ Jan 03 19:29:12 sounds like it MIGHT be a bug.. in cases like this what I've normally done is put a wrapper on it that sets the M4 path to the "right place" and then calls the actual binary.. so any embedded path simply doesn't matter Jan 03 19:29:28 hmmm having staging path is wrong Jan 03 19:30:11 and staging path for target m4 should be stripping out target sysroot and jusr /usr/blah/blah Jan 03 19:31:43 probably the best fix here is to only hardcode the binary name and not the path Jan 03 19:32:06 it should have happened automatically Jan 03 19:32:19 is it a call in a script ? Jan 03 19:33:17 khem, the flex configure.in script uses AC_PATH_PROG and then uses AC_DEFINE to embed the full path in config.h for C code Jan 03 19:34:33 i think changing it to AC_CHECK_PROGS will work Jan 03 19:34:47 * walters uses his new import of flex into git and tests a patch Jan 03 19:36:27 yes that should be AC_CHECK_PROGS Jan 03 19:51:35 fray: ping Jan 03 19:51:57 here Jan 03 19:52:11 fray: is the prelink git i should test: bb1b660c5e3859b6c5a2ac8d739713e9989a4dd7 Jan 03 19:52:59 verified.. yes thats the one Jan 03 19:53:01 that appears to be the prelink-cross master Jan 03 19:53:19 there were a few corner cases where the ld.so emulation could have given the wrong results before.. Jan 03 19:53:22 those should be corrected Jan 03 19:55:54 fray: doing a build now Jan 03 19:56:25 thanks! Jan 03 20:20:06 fray: look at that… it's working now =) Jan 03 20:20:21 -excellent-.. so it was one of the corner cases Jan 03 20:20:56 a more recent one Jan 03 20:21:11 i think I tested a new prelink sometime between the bug filling and this test today Jan 03 20:29:08 fray: ugh, i tested the wrong stuff Jan 03 20:29:15 fray: grr Jan 03 20:29:37 ha Jan 03 20:32:01 here's to hoping it still works Jan 03 21:17:10 fray: it's not working Jan 03 21:17:14 i get this in do_rootfs: /local/home/mattsm/git/poky/build_p5020ds-64b_release/tmp/sysroots/x86_64-linux/usr/sbin/prelink: /lib64/libc.so.6 Could not trace symbol resolving Jan 03 21:17:35 that is different hten before right? Jan 03 21:18:20 fray: then i added what happens on the board to the bug Jan 03 21:18:28 im not 100% sure, let me look Jan 03 21:18:29 ok Jan 03 21:19:10 fray: no this is what I always saw Jan 03 21:19:11 http://bugzilla.pokylinux.org/show_bug.cgi?id=1531 Jan 03 21:19:17 that's the duplicate hidden bug Jan 03 21:19:19 ok.. so it hasn't changed.. damn Jan 03 21:19:21 kumar saw something different Jan 03 21:19:36 but we have not seen that in a while Jan 03 21:19:56 just to verify -- your lib directory is lib64? Jan 03 21:21:39 fray: yes Jan 03 21:21:58 fray: where there any other fixes in master? I'm working off an "edison like" branch Jan 03 21:22:12 so i just updated the prelink git SHA basically Jan 03 21:23:43 ya.. there are some conditions that the wrong library paths are looked up.. Jan 03 21:24:13 so it's worth moving to this version.. Jan 03 21:31:36 fray: i did that, but there are no other hidden fixes im missing? Jan 03 21:32:15 not related to prelinking.. Jan 03 21:32:25 moving forward to the latest version of cross_prelink is the right way to do it Jan 03 21:34:07 hm, so this m4 issue is more widespread than i thought...bison does the same thing, and so does autoconf itself - it even recommends the exact pattern in the manual Jan 03 21:35:34 i guess no one has really tried much to use yocto-built development tools on the target Jan 03 21:37:26 walters: look in classic oe what we did there Jan 03 21:37:45 since classic oe has been used on target to do further builds Jan 03 21:38:26 khem, link? Jan 03 21:40:02 fray: if I prelink on the target… what will that tell me? Jan 03 21:40:41 vs. cross prelink? Jan 03 21:40:42 walters: there were some path adjustments done for some devtools for target Jan 03 21:40:52 I dont remember exactly when it was done Jan 03 21:41:09 thinking... Jan 03 21:42:30 yes.. there are two things you should try.. Jan 03 21:42:54 the first is trying to run it as-is.. if it suddenly works.. this points to an endian problem... but be prepared for it to mangle the system.. :( Jan 03 21:43:34 otherwise pass it (the prelinker) --dynamic-linker=... looking it up now Jan 03 21:44:40 fray: ok so im adding prelink to a non-prelink rfs Jan 03 21:46:44 no wonder.. I'm looking at the wrong code! Jan 03 21:46:45 damn Jan 03 21:48:12 wrong arg.. you want to pass --rtld "" to the prelinker.. this disables the custom ld.so emulation, and falls back to using the -real- ld.so on the filesystem Jan 03 21:48:36 if --rtld "" works, and running w/o that doesn't.. then it's an emulation problem.. if neither works.. the problem is in the core prelinker code Jan 03 21:48:39 im doing this on the build system or the target? Jan 03 21:48:51 on the target system Jan 03 21:49:01 i.e. prelink -a Jan 03 21:49:10 that is likely to fail -- if it doesn't.. then it's an endian issue.. Jan 03 21:49:21 prelink --rtld "" -a Jan 03 21:49:51 if that fails (in the same way) means it's a problem with the core rpelinker code and not the ld.so emulation Jan 03 21:54:05 UGH.. kid has discovered netflix.. and the lag is horrible.. Jan 03 21:54:13 * fray goes to (not really) beat the kid over the head Jan 03 21:56:14 -much- better.. I can type -and- see the response now Jan 03 22:02:35 fray: prelink -a Jan 03 22:02:37 gives me: prelink: Could not rename temporary to /usr/sbin/prelink-rtld: Invalid cross-device link Jan 03 22:02:40 a lot of those Jan 03 22:02:55 well that is simply broken and not right Jan 03 22:03:21 well Jan 03 22:03:30 the issue is that there is an internal switch on which rtld to use Jan 03 22:03:38 its my rfs =) Jan 03 22:03:38 prelink: Could not write prelink cache: No space left on device Jan 03 22:03:40 I was trying to get it to flip the switch, which appears to not have worked Jan 03 22:03:42 i need to install this somewhere Jan 03 22:03:51 Or... it could be that ;) Jan 03 22:32:51 fray: prelink -a works ok Jan 03 22:33:10 thats on the target? no warnings? Jan 03 22:33:20 fray: on target Jan 03 22:33:21 no warnings Jan 03 22:33:31 what do I do test test after that though? Jan 03 22:33:31 ok, then we may have an endian / bitsize issue.. damn Jan 03 22:33:54 I don't have a PPC64 system to be able to play with.. Jan 03 22:34:03 the obvious case is that something is wrong with the prelinker RTLD.. Jan 03 22:34:12 i have not done —rtld yet Jan 03 22:34:26 just "prelink -a" Jan 03 22:34:29 did you build the cross prelinker sources or the "prelinker" sources? Jan 03 22:34:43 i did IMAGE_INSTALL += "prelink" Jan 03 22:34:47 if you built the cross prelinker sources (for the trget) then prelink -a is cross prelinling.. Jan 03 22:34:56 check to see if you have the binary prelink-rtld on your fs Jan 03 22:35:08 yes I do Jan 03 22:35:30 ya.. it cross prelinked then.. ;) Jan 03 22:35:42 oh ok Jan 03 22:35:45 so that is the ld loader now? Jan 03 22:35:53 it emulates the loader.. Jan 03 22:35:57 ok Jan 03 22:36:04 so what I'd suggest you do is run... (finding the magic) Jan 03 22:36:07 im obviously not fully up to speed how this all works Jan 03 22:36:24 we didnt actually replace the loader though? we just made this? Jan 03 22:36:56 we only replace the loader for the prelinker.. and this is for the cross case.. there is no way (short of removing patches) to disalbe the cross-loader (emulator) Jan 03 22:37:11 * msm starts reading wiki page Jan 03 22:37:16 what I would suggest is running (on the target --and-- the host.. capturing the output and comparing) Jan 03 22:37:32 RTLD_TRACE_PRELINKING=1 prelink-rtld Jan 03 22:37:50 I think you said that the libc had a private symbol that went away.. or something.. start there.. Jan 03 22:38:03 if you can identify a difference in the output, it can lead us to the cause and a possible solution.. Jan 03 22:39:47 (on the host side, you will likely need to pass in --root= --target-paths) Jan 03 22:40:03 i see kumar's steps in the bug Jan 03 22:45:59 fray: im seeing some conflicts on the host Jan 03 22:45:59 conflict 0x00000000dead2000 0x0000000000000408 -> 0x00000000dead1000 0x000000000019dee8 x 0x00000000dead2000 0x0000000000035b40 /1 __libc_memalign Jan 03 22:46:06 with prelink-rtld Jan 03 22:46:20 is that an issue? Jan 03 22:46:22 conflicts should be normal Jan 03 22:46:29 but you should also see them on both sides Jan 03 22:46:55 i should compare the prelink-rtld output from both sides? Jan 03 22:47:03 ya.. they should be identical Jan 03 22:48:54 not identical Jan 03 22:49:07 target: # RTLD_TRACE_PRELINKING=1 prelink-rtld /usr/bin/find | grep ge Jan 03 22:49:07 lookup 0x00000000dead0000 0x0000000000001ec0 -> 0x00000000dead1000 0x00000080011dfc28 /1 getgrouplist Jan 03 22:49:17 host: $ RTLD_TRACE_PRELINKING=1 ./tmp/sysroots/x86_64-linux/usr/sbin/prelink-rtld --root=rfs/ --target-paths /usr/bin/find | grep getgrouplist Jan 03 22:49:17 lookup 0x00000000dead0000 0x0000000000001e88 -> 0x00000000dead1000 0x000000000019fc28 /1 getgrouplist Jan 03 22:50:23 format is: type, addr, offset -> new addr, new offset /? name Jan 03 22:50:38 it looks to me like one of those two has been prelinked and the other hasn't Jan 03 22:50:40 thus the difference Jan 03 22:50:43 oh Jan 03 22:50:52 because im still running on my 'prelink -a' rfs Jan 03 22:50:54 on the target you should be able to ru prelink -u -a Jan 03 22:51:04 that should unprelink and let you retry Jan 03 22:51:07 ah Jan 03 22:51:10 rebooting already Jan 03 22:51:12 be a sec Jan 03 22:51:22 on the "older" binary: Jan 03 22:51:24 oops Jan 03 22:57:33 hmm Jan 03 22:57:47 which of the above is already prelinked... Jan 03 22:57:49 the target? Jan 03 22:58:59 ugh I'm not even sure.. just the adress after the -> looks too big.. which makes me thing the relocation has been set Jan 03 22:59:04 (which indicates prelinked) Jan 03 22:59:52 thats what i thought Jan 03 23:00:04 which is weird because i think my rfs is prelinked Jan 03 23:00:22 it doesnt prelink at boot if I added prelink to my rfs? Jan 03 23:00:28 yes Jan 03 23:00:29 it does Jan 03 23:00:30 grr Jan 03 23:00:38 Running postinst /etc/rpm-postinsts/prelink.sh... Jan 03 23:00:42 ahh Jan 03 23:01:27 the new target: lookup 0x00000000dead0000 0x0000000000001e88 -> 0x00000000dead1000 0x000000000019fc28 /1 getgrouplist Jan 03 23:01:39 ok let me do a full diff Jan 03 23:03:44 this is the only diff: - libc.so.6 => /lib64/libc.so.6 (0x00000000dead1000, 0x00000000dead1000) TLS(0x1, 0x0000000000000000) Jan 03 23:03:44 + libc.so.6 => /lib64/libc.so.6 (0x00000000dead1000, 0x00000000dead1000) TLS(0x1, 0x0000000000000000) Jan 03 23:03:56 err Jan 03 23:03:58 that is just whitespace Jan 03 23:04:36 ok... if that is the only difference then the problem is most likely -not- in the prelink-rtld Jan 03 23:04:45 but it's likely in the "prelink" itself.. (or possibly libelf) Jan 03 23:05:29 endian issues? Jan 03 23:05:47 I'm just guessing endian or bit size.. Jan 03 23:06:02 something is different from your host sytem and target causing the same problem to work on the target and not host Jan 03 23:06:19 endian is the likely culpret based on what I've seen go wrong in the past Jan 03 23:06:44 is there any 64-bit non-ppc non-x86 system? =) Jan 03 23:06:59 MIPS.. ;) but we don't support it yet in OE-core Jan 03 23:07:50 well Jan 03 23:07:56 i need to run for now… thanks for the debugging help Jan 03 23:09:00 yup.. have a good one Jan 04 00:33:26 hm, so i have this pretty tiny install manifest: http://pastebin.mozilla.org/1432739 that somehow blows up into: http://pastebin.mozilla.org/1432741 Jan 04 00:34:06 is there a good way to extract out of zypper what package is being added because of another? Jan 04 00:34:52 task-core-boot will bring in a bunch of stuff, I expect Jan 04 00:34:57 and I think strace brings in perl Jan 04 00:35:00 huh Jan 04 00:35:06 but what could be bringing in gtk+? Jan 04 00:35:24 http://pastebin.mozilla.org/1432742 Jan 04 00:35:30 oh, missed that one in all the perl Jan 04 00:35:33 looks pretty minimal Jan 04 00:35:43 agreed Jan 04 00:35:58 task-core-sdk-dev? Jan 04 00:36:24 yeah i think it must be that, but Jan 04 00:36:31 http://pastebin.mozilla.org/1432744 Jan 04 00:36:39 oh maybe it's task-core-sdk... Jan 04 00:37:01 seems likely Jan 04 00:37:19 i think at one point i experimented with adding gtk+ to my yocto root but then got rid of it Jan 04 00:37:54 trying to make it more minimal now and move more things over to my self-hosting ostbuild Jan 04 00:44:20 oh it may be distcc Jan 04 00:44:27 ick Jan 04 00:44:31 it has a gtk+ gui? Jan 04 00:44:35 yes it's distcc Jan 04 00:44:38 yep Jan 04 00:44:40 we need to split that out into a separate package then :-/ Jan 04 00:44:48 yeah, distcc-dev Jan 04 00:44:51 hey bluelightning! burning the midnight oil? Jan 04 00:44:55 is pulled in by task-core-sdk-dev Jan 04 00:44:57 we had this discussion a couple of months ago if you recall Jan 04 00:45:06 it is already split Jan 04 00:45:09 me? I don't recall it Jan 04 00:45:11 it's the -dev package that's problematic Jan 04 00:45:19 incandescant: not with you, I mean on the mailing list Jan 04 00:45:20 hmm Jan 04 00:45:36 bluelightning: oh, I long ago stopped trying to follow all conversations on all our lists :-/ Jan 04 00:45:45 http://pastebin.mozilla.org/1432766 Jan 04 00:45:48 walters: traditionally we don't split dev packages, but that's not to say we can't Jan 04 00:46:28 incandescant: yeah just trying to tidy up a few things Jan 04 00:46:43 probably i should just stop using task-core-sdk-dev since i don't want tcl either, but Jan 04 00:47:43 http://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg11783.html Jan 04 00:48:37 why is yocto generating an empty distcc-dev package? Jan 04 00:49:03 just for consistency so everything has a -runtime and -dev ? Jan 04 00:49:15 walters: yes I believe so Jan 04 00:50:16 hm, i am confused why the empty package has those dependencies...is the rule that default generated -dev packages have a Requires: on the RPMs corresponding to whatever the bitbake recipie pulled in via DEPENDS? Jan 04 00:52:37 walters: yes, see the "RDEPENDS_${PN}-dev ..." line in meta/conf/bitbake.conf Jan 04 00:52:45 ok Jan 04 00:53:23 i'm not sure of a clean way to fix this then, suggestions appreciated; if nothing is obvious i'll just stop using task-core-sdk-dev and pull in the things i want explicitly Jan 04 00:56:56 or hm, maybe i shouldn't be pulling in the -dev package for task-core-sdk Jan 04 00:57:58 iirc that caught me with some basic stuff missing, but the non-dev package already has an RDEPENDS on libstdc++-dev, so maybe i just need to add more explicit -dev packages there Jan 04 00:58:58 if you just want -dev packages for things already in your image you could try adding dev-pkgs to IMAGE_FEATURES? Jan 04 00:59:25 that would get me the -dev package for distcc, no? Jan 04 00:59:37 which is the source of the problem Jan 04 01:01:47 oh, you want distcc? Jan 04 01:02:13 well not really =) Jan 04 01:02:21 or are you getting distcc because of qemu-config? Jan 04 01:02:31 i want enough to run gcc on the target Jan 04 01:02:40 which task-core-sdk is mostly doing Jan 04 01:03:13 or maybe more precisely stated, enough that i can build ostree (which depends on glib) Jan 04 01:03:37 which in turn depends on libc headers, gcc, autoconf, automake, libtool, etc. Jan 04 01:10:34 walters: we are working on a self-hosted build image, parts of it are already in oe-core, not sure if that's what you want or not. I am coming in on the tail here so maybe it's already been discussed. Jan 04 01:10:37 indeed, looking better: http://pastebin.mozilla.org/1432784 Jan 04 01:11:22 sgw, but you don't have a story yet for how you install modified components onto the running system, right? Jan 04 01:13:09 the running build system or another system running the image? That story would be a package feed and package managment tools, but you are right that is not yet part of the self hosted build infrastructure. Jan 04 01:13:18 yeah, way too slow for me Jan 04 01:13:37 and rpm doesn't have rollback, so if you're hacking on glib you can easily break your system Jan 04 01:14:17 sgw, i'm not yet ready to announce ostree widely since i have a lot left to prove, but you can see my thoughts here: http://git.gnome.org/browse/ostree/tree/README.md Jan 04 01:16:43 walters: thanks, I will take a look at this. Jan 04 01:49:44 ah hah, pkg-config-dev Jan 04 01:50:18 er, pkgconfig-dev Jan 04 01:53:51 but that Requires: libglib-2.0-dev, which then in turn requires dbus-dev which requires libx11-dev which... =( Jan 04 01:54:29 i think basically the fact that -dev packages both contain development files and also automatically require everything used to build them is problematic **** ENDING LOGGING AT Wed Jan 04 02:59:58 2012