**** BEGIN LOGGING AT Thu Apr 18 02:59:58 2013 Apr 18 06:43:55 morning all Apr 18 07:25:18 good morning Apr 18 07:28:43 morning all, hi bluelightning , hi mckoan , all Apr 18 08:40:15 bitbake -e shows that MACHINE is UNSET, is it normal when building an SDK recipe ? what to do when some libs are put inside the machine sysroot ? Apr 18 08:53:42 good morning Apr 18 08:54:20 Hi bluelightning, mckoan, silvio__ Apr 18 08:56:20 hi apelete Apr 18 09:01:34 hi apelete, silvio__ Apr 18 09:01:43 hi mckoan Apr 18 09:10:53 hello Apr 18 09:16:11 hi mckoan, silvio__, bluelightning, all Apr 18 09:16:19 hi pb_ Apr 18 09:18:36 hi pb_ Apr 18 09:18:46 hi hrw Apr 18 09:52:03 1. http://www.amazon.com/gp/product/B0046A8YF8/ref=oh_details_o01_s02_i03?ie=UTF8&psc=1 Apr 18 09:52:06 ops Apr 18 09:52:08 | checking for arm-oe-linux-gnueabi-gcc... arm-linux-gnueabihf-gcc -march=armv7-a -marm -mthumb-interwork -mfloat-abi=hard -mfpu=neon --sysroot=/home/hrw/HDD/devel/canonical/aarch64/openembedded/build/tmp-eglibc/sysroots/genericarmv7a -march=armv7-a -marm -mthumb-interwork -mfloat-abi=hard -mfpu=neon -isystem/home/hrw/HDD/devel/canonical/aarch64/openembedded/build/tmp-eglibc/sysroots/genericarmv7a/usr/include --sysroot=/home/hrw/HDD/devel/canonical/aarch64/openembedded/bu Apr 18 09:52:27 does someone know where from gcc takes second set of -march -mfloat-abi? Apr 18 10:07:51 multilib... Apr 18 10:12:31 is there a way to tell that external-toolchain is not multilib compatible? Apr 18 10:23:58 hi JaMa, r u online? Apr 18 10:51:46 silvio__: y Apr 18 10:53:47 JaMa, do u know this: http://shr.bearstech.com/tests/jama :) Apr 18 10:58:13 what about it? Apr 18 11:01:24 silvio__: if you're surprised it's public, then it's meant to be public Apr 18 11:06:29 hello guys Apr 18 11:06:44 is BBFILE_PRIORITY is higher than PREFERRED_VERSION Apr 18 11:07:27 IIRC no Apr 18 11:08:34 like if we have PREFERRED_VERSION set to such version which lies in lower Priority layer then PREFERRED_VERSION will be honored or the recipe that is present in high priority layer will be honored Apr 18 11:10:20 P_V should be honored Apr 18 11:16:42 JaMa: thanks Apr 18 11:27:51 ok, as I had power loss I will retry question Apr 18 11:28:07 does someone know how to mark external toolchain as multilib not capable? Apr 18 11:51:01 morning all Apr 18 11:58:03 hrw: you could check multilib vars and just raise SkipPackage if set Apr 18 12:02:59 JaMa, not surprise of public, i found it and I think if is yours Apr 18 12:05:40 yes shr and jama is high probability that it's mine :) Apr 18 12:19:57 hello, I have a PPC-binary, which throws a SIGSEGV at startup Apr 18 12:20:15 if I call ltrace, I get a Couldn't get section header from "./Main" Apr 18 12:20:56 its a static linked ELF: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, for GNU/Linux 2.6.22, with unknown capability 0x41000000 Apr 18 12:21:53 I cannot even run it with gdb, gdb complains that there is no executable file specified Apr 18 12:54:09 hmm, i have some problems to compile qt4. I have paste it to this pasty-service: http://pastie.org/private/oft6ttf8whvz0a13qmwcq -- have someone a solution for this? Apr 18 13:33:53 RP, are the lists behaving any better today? Apr 18 13:38:56 Crofton|work: I've noticed less problems... Apr 18 14:42:11 hello, again I have a really weird problem Apr 18 14:42:21 I made a powerpc ELF-binary (Main: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, for GNU/Linux 2.6.22, with unknown capability 0x41000000) Apr 18 14:42:33 which cannot be envoked on my platform, Apr 18 14:42:47 if I call it, I get an segmentation fault: SIGSEGV - core dumped Apr 18 14:43:03 as it seems, the binary is not the problem, but the linux system beneath Apr 18 14:43:24 because if I transfer this binary to anoter ppc-system of the same architecture, (walnut-ppc-board with ppc405gp) it works. Apr 18 14:43:59 but not on my system. what can I check to see the properties of my linux-system? Apr 18 14:46:37 I cannot even call strase or ltrace, : ltrace: Couldn't get section header from "./Main" Apr 18 14:47:28 I can call the binaries in my busybox, and even gdb Apr 18 14:48:52 but if I try to load this binary within my gdb, gdb complains, that there is no executable file specified Apr 18 14:49:03 has anybody a clue? Apr 18 14:54:52 chrishell: how this issue should be related to OE ? Apr 18 15:01:44 mckoan: where should I else ask about problems with cross-compiling for embedded boards? Apr 18 15:15:11 chrishell: some PowerPC channel or ML ? Apr 18 15:15:32 chrishell: are you generating a system with OE ? Apr 18 15:23:07 * pb_ stabs eglibc Apr 18 15:23:10 configure: error: Need linker with .init_array/.fini_array support. Apr 18 15:32:51 mckoan: not yet, I must confess :-[, but I would like Apr 18 15:46:59 i am working on a qtserialport recipe right now and to start off i am trying to build qtserialport using a qte toolchain I build yesterday Apr 18 15:47:35 I get an error from ld: cannot find -lQtCore Apr 18 15:48:03 which turns out to be due to the fact that this library is actually named QtCoreE in the qte toolchain Apr 18 15:50:48 waynr: pastebin your recipe may help Apr 18 15:50:49 waynr: does your recipe inherit qt4e ? Apr 18 15:51:31 it should if you want to build against qte Apr 18 15:51:55 mckoan, bluelightning I have not actually tried to build using bitbake, just using the generated SDK Apr 18 15:53:54 but i have added that line to the workinprogress recipe now Apr 18 15:54:14 * waynr will just build from bitbake and see what happens Apr 18 15:54:44 doh, poxy eglibc doesn't run autoreconf. Apr 18 15:54:47 * pb_ stabs it again Apr 18 15:56:27 *stab*stab*stab* Apr 18 15:56:34 exactly Apr 18 16:00:21 waynr: the environment setup script provided with the qte toolchain should be setting up the environment appropriately though... Apr 18 16:00:49 have a nice rest of the day Apr 18 16:01:39 bluelightning: the issue is that qtserialport by default expects the QtCore library whereas the qte toolchain provides QtCoreE instead Apr 18 16:08:01 waynr: it doesn't look like there's any hardcoded reference to -lQtCore in the qtserialport source Apr 18 16:08:41 waynr: is QT_LIBINFIX set in the environment? Apr 18 16:08:54 let me check Apr 18 16:09:46 bluelightning: nope Apr 18 16:10:53 waynr: ok, that should be set to E Apr 18 16:13:23 okay i ran 'export QT_LIBINFIX=E', cleared out my build directory, then re-ran qmake on qtserialport.pro, then ran 'make' but still get the same error Apr 18 16:16:53 I could ahve sworn we had code which added rdepends for python modules based on what modules they import, but I'm not finding it now, maybe such a thing never got implemented Apr 18 16:16:57 This ring a bell for anyone? Apr 18 16:17:17 I know we have this logic for kenrel modules, but i swear perl/python had something, or at least we wanted them to have something Apr 18 16:17:20 * kergoth scratches head Apr 18 16:18:13 waynr: hmm, I'm not sure... the thing that puzzles me is that variable should be being set by the environment setup script Apr 18 16:18:22 waynr: are you definitely running that script? Apr 18 16:18:44 kergoth: no, I don't think we ever got to doing that Apr 18 16:18:56 ah Apr 18 16:19:08 gm Apr 18 16:19:09 kergoth: I asked the same thing a while ago and apparently one of the previous python maintainers in OE was expressly against it Apr 18 16:19:11 Hmm, I bet it wouldn't be terribly hard to throw something together with the ast module Apr 18 16:19:16 Huh Apr 18 16:19:30 I mean, yeah, it won't catch every case, if someone goes running __import__() or something Apr 18 16:19:44 I guess one could make an argument that it's too "magic", too implicit, rather than explicit Apr 18 16:19:52 I think it would save a lot of work myself, so if you can come up with something that works, I say go for it for what that's worth ;) Apr 18 16:19:52 and we have more than enough magic already Apr 18 16:19:56 * kergoth shrugs Apr 18 16:19:57 * kergoth nods Apr 18 16:20:58 I know I really hated the trial-and-error setting of dependencies for ajenti when I wrote the recipe for that... Apr 18 16:23:01 ugh, yes, that would be really annoying. run script, fail, install package, rinse, repeat, and thats assuming you have a feed, otherwise repeated image creations go in that cycle Apr 18 16:23:06 bluelightning: looks like in the version of poky that i am using none of meta-toolchain-qt.inc, meta-toolchain-qt.bb, or meta-toolchain-qte.bb add QT_LIBINFIX=E in the "toolchain_create_sdk_env_script_append" Apr 18 16:23:33 which given my limited knowledge of the qt toolchain generation is where I would expect that variable to be appended to the sdk env script Apr 18 16:25:46 waynr: the creation of the script is done as part of qt4.inc in the qt recipes I believe Apr 18 16:26:17 kergoth: yep, it was the latter for me (I could have just set up a feed I suppose) Apr 18 16:27:16 bluelightning: I see the toolchain_create_sdk_env_script_append() in recipes-qt/meta/meta-toolchain-qt.inc Apr 18 16:28:01 I just checked out tag 1.4_M6.rc1 to see if it has changed since the version i am using, it hasn't Apr 18 16:29:19 ah wait, i do see a different environment-setup script being created in the recipe you mention Apr 18 16:29:33 bluelightning: http://www.rpm.org/ticket/154 - heh, figured i'd search and see if it handled it on its end, the answer is no, but the info there may be of use :) Apr 18 16:29:45 and that one does include QT_LIBINFIX Apr 18 16:30:03 waynr: they do look like they overlap a little... Apr 18 16:30:38 which is not really ideal I would have to admit Apr 18 16:32:18 for the SDK, the environment-setup script created by the qt4.inc recipe ends up in the target sysroot under usr/share/qtopia Apr 18 16:34:25 morning kergoth Apr 18 16:34:39 hey pb_, how's it going? Apr 18 16:34:47 i am guessing that QT_LIBINFIX is set by either the qt4 or the qt4e class? Apr 18 16:34:50 Hi - I have a problems to compile qt4. I get a "/usr/src/kernel/include/linux/stddef.h:12:2: error: expected identifier before 'false'" here is the full error: http://pastie.org/private/oft6ttf8whvz0a13qmwcq -- Have someone a advice for me? Apr 18 16:35:18 kergoth: not too bad. in the middle of trying to update my oe-core snapshot, which is always a bit painful. Apr 18 16:35:27 heh, indeed Apr 18 16:35:38 eglibc 2.17 is failing to build because of a bad interaction between its configure script and my CFLAGS. Apr 18 16:35:52 that sounds unpleasant Apr 18 16:36:05 and fixing it is tedious because it doesn't use autoreconf, need to patch the configure script directly in about half a dozen places. Apr 18 16:36:25 a, qt4e vs qt4x11 Apr 18 16:40:22 waynr: indeed yes Apr 18 16:47:02 Hmm. Apr 18 18:41:40 No OE recipe for Gtk 3.4.4 gnome-themes ? Apr 18 18:42:43 for qtserialport nothing is getting installed in ${WORKDIR}/image, instead everything is going to tmp/sysroots/x86_64-linux Apr 18 18:43:25 * waynr gonna pastebin the recipe Apr 18 18:46:22 http://paste.debian.net/250334 Apr 18 18:46:43 not sure, but I think i need to change something about the configure step Apr 18 18:52:14 basing this recipe on qextserialport Apr 18 18:52:48 which does populate image correctly Apr 18 18:55:01 probably the biggest problem is my lack of familiarity with qt and qmake in general Apr 18 19:13:22 can someone do test build? 'bitbake icu;bitbake openldap' without sstate-cache. then remove tmpdir and do 'bitbake openldap' Apr 18 19:18:46 waynr check the .pro file Apr 18 19:19:44 woglinde: what should I look for Apr 18 19:22:26 either you are familiar with the pro-file or not Apr 18 19:24:09 i know where the top-level .pro file is for this project and I have that set in QMAKE_PROFILES Apr 18 19:25:51 somehow it seems like the host sysroot is getting passed in to qmake, probably from an environment variable during the configure process? Apr 18 19:26:02 * waynr begins reading qt development manual Apr 18 19:27:05 i think ${D} should be given instead of the host sysroot Apr 18 19:33:44 hrw: heh, openldap pull in icu conditionally? Apr 18 20:11:27 kergoth: yes. Apr 18 20:11:40 kergoth: and only checks for headers Apr 18 20:12:15 * kergoth nods Apr 18 20:12:35 * kergoth still pines for per-recipes sysroots someday far from now Apr 18 20:13:18 kergoth: I will create some ugly patch to just kill it Apr 18 20:14:18 heh, after all the practice over the years we can probably fix those sorts of problems blindfolded :) Apr 18 20:16:34 ;) Apr 18 20:18:32 When I build my angstrom image, angstrom-version gets re-built every time. How does that happen and how I make the same thing happen for another package? Apr 18 20:18:48 how ^do^ I Apr 18 20:19:04 ok. slapd (whatever it is) depends on icu Apr 18 20:55:58 i am stuck on this qtserialport recipe Apr 18 20:59:51 i am really starting to dislike qt Apr 18 21:14:10 waynr: that's when you know you're doing something interesting Apr 18 21:22:58 sr105: thanks, hopefully i can figure this out by the end of the day Apr 18 21:24:37 next thing to try...learn about makespecs and what variables they use to set up install targets Apr 18 21:26:20 i am just baffled as to why/how qextserialport is being set up properly but qtserialport isn't...maybe there is a different from inheriting qt4e instead of qt4x11? Apr 18 21:28:26 Hmm, I wonder if my greedy-deps-tests script woul dhave found the icu/openldap one if i ran it against it Apr 18 22:07:30 i swei see what appears to be an internal value in the qmake2 binary called "qt_prfxpath=/path/to/sysroots/x86_64-linux/usr" which in my is the problematic path in generated Makefiles Apr 18 22:51:59 man do I love 'bb log' Apr 18 23:00:18 sneak peak for now useful tool you're cooking? Apr 18 23:00:24 now/new Apr 18 23:07:04 JaMa: 'bb' is a work in progress subcommand-baseds bitbake inspection tool, 'log' is a subcommand for it contributed by ross burton. 'bb log' -> shows cooker log. 'bb log somerecipe' -> shows the most recent task log for somerecipe. bb log somerecipe sometask.. Apr 18 23:07:32 JaMa: see https://github.com/kergoth/bb Apr 18 23:07:50 haven't had time to work on it in some time, but some of the commands are quite handy Apr 18 23:15:07 I remember reading about bb before and I also found it useful, just haven't tried it yet and assumed that log is new subcommand Apr 18 23:15:33 pretty new, yeah Apr 18 23:15:44 there's also bb-contents which shows you what files are in the binary packages for a given recipe Apr 18 23:16:09 I need to remove bb alias from my build environments first Apr 18 23:16:14 hehe Apr 18 23:16:22 now we're using bb just to call bitbake with some extra params Apr 18 23:16:49 you can run the subcommands with - too in most cases, at worst you could add the libexec dir to PATH explicitly Apr 18 23:16:53 e.g. bb-log, bb-contents Apr 18 23:17:28 yes but it will be confusing for people to read about bb tool and then be surprised by bb alias not working as expected Apr 18 23:18:40 I mean the bb alias is in setup-scripts for SHR and webos-ports.. so not only my local build environments.. Apr 18 23:18:44 ahh, right Apr 18 23:18:47 makes sense Apr 18 23:19:21 could have called it bb-inspect or something, but in the long term I want it to be useful for doing builds and the like with a subcommand interface too Apr 18 23:21:10 I think it's nice that it's short Apr 18 23:22:09 * JaMa using 2-4 letters long aliases for most of common tasks Apr 18 23:22:52 well 1-4, but only a few in first group :) Apr 18 23:23:41 * kergoth nods Apr 18 23:24:05 * kergoth needs to find the time to finish it up and get a 1.0 out Apr 18 23:36:23 i'm just gonna sed out the junk paths from the generated makefiles Apr 18 23:37:03 time to patch qmake? ;) Apr 18 23:38:01 i just find it maddening that it's not doing this for any other projects like qwt or qextserialport Apr 18 23:38:37 what effect would patching qmake just so qtserialport configures correctly have an other projects? Apr 18 23:39:02 good question, that's odd Apr 18 23:40:04 that path isn't the problem Apr 18 23:40:30 it's just the default path, you need to be influencing the actual path used via configuration Apr 18 23:40:41 in the .pro files? Apr 18 23:40:55 usually it's via the qmakespec file Apr 18 23:42:32 okay i will look into that again Apr 18 23:43:22 having spend a lot of time in meta-qt5 I find this whole mkspecs/qt.conf/configure+qmake combo very fragile :/ Apr 18 23:44:11 well this project is not using configure, just qmake, then make, then make install Apr 18 23:45:12 but yeah, i can only image how frustrating qt5 must be Apr 18 23:46:33 s/image/imagine Apr 18 23:56:03 hmm bitbake does slow down considerably when running three separate instances each in a different build directory Apr 18 23:56:36 if only i had left my raspi at home on I could WOL my quadcore desktop and use that also :( Apr 18 23:57:16 maybe amazon aws would be a worthy investment Apr 18 23:58:25 having load 25+ slows everything down considerably here :) Apr 18 23:59:18 I'm glad that todays linux desktop does handle it pretty well and low-demanding stuff like irssi works fine under high load Apr 19 00:27:50 okay so qwt definitely uses a different mkspec (qt4/mkspecs/linux-oe-g++ vs qtopia/mkspecs/linux-oe-g++) Apr 19 00:31:16 damn changing the mkspec did not change the Makefile output Apr 19 00:36:17 interesting to observe task-by-task how different recipes accomplish similar goals (qwt vs qextserialport) Apr 19 02:37:13 wooo it works Apr 19 02:38:05 in the end i just sed all generated Makefiles in do_compile_append such that `qmake2 -query QT_INSTALL_PREFIX` is replaced with ${prefix} Apr 19 02:38:08 magic Apr 19 02:39:05 * waynr handwaves the problem away **** ENDING LOGGING AT Fri Apr 19 02:59:58 2013