**** BEGIN LOGGING AT Thu Jul 02 02:59:57 2009 Jul 02 07:36:56 gm Jul 02 08:59:33 morning Jul 02 09:05:19 florian: good morning Jul 02 09:06:42 morning Jul 02 09:08:47 good morning Jul 02 09:09:13 hi florian valhalla Jul 02 09:10:27 good morning Jul 02 09:15:41 What heppenens here ? NOTE: The MD5Sums did not match. Wanted: '9d22ee4dafa3a194457caf4706f9cf01' and Got: 'd41d8cd98f00b204e9800998ecf8427e' Jul 02 09:16:18 NOTE: Task failed: Checksum of 'ftp://ftp.gnu.org/gnu/binutils/binutils-2.18.tar.bz2' failed Jul 02 09:16:18 sgh: did you check if it was a simple download error? Jul 02 09:22:46 d22ee4dafa3a194457caf4706f9cf01 binutils-2.18.tar.bz2 Jul 02 09:22:54 just fetched from ftp://ftp.gnu.org/gnu/binutils/binutils-2.18.tar.bz2 Jul 02 09:23:06 sgh: your fetch was broken Jul 02 09:23:34 sgh: remove binutils-2.18.tar.bz2* from DL_DIR, clean binutils(-cross) and build Jul 02 09:39:57 where should local m4 files go for autoreconf to be happy? Jul 02 09:40:08 it seems that [e ]glibc is broken again for x86 and i586-generic: do_compile dies with an undefined reference to ` Jul 02 09:40:11 __i686.get_pc_thunk.bx Jul 02 09:40:16 I get aclocal: acinclude.m4:639: file `qt.m4' does not exist Jul 02 09:40:23 qt.m4 is in ${S}/m4 Jul 02 09:41:56 booxter: and -Im4 is in the commandline too? Jul 02 09:42:18 zecke_: where should it go? Jul 02 09:42:36 EXTRA_OECONF? Jul 02 09:43:12 valhalla: which version of glibc? Jul 02 09:45:30 latest try was eglibc_2.9 Jul 02 09:50:41 booxter: inside the configure.in/configure.ac or such Jul 02 09:54:14 valhalla: I think the checksum is wrong Jul 02 09:54:58 sgh: both the eglibc and the glibc checksums? Jul 02 09:55:16 sgh: no, sorry, that was about the pervious topic Jul 02 09:55:50 sgh: did you read the solution by hrw? Jul 02 09:55:51 valhalla: yes ... unless the files fetched is altered :( Jul 02 09:56:11 valhalla: no Jul 02 09:56:34 < hrw> sgh: remove binutils-2.18.tar.bz2* from DL_DIR, clean binutils(-cross) and build Jul 02 09:59:10 sgh: checksum is proper Jul 02 09:59:47 sgh: your fetch is not Jul 02 10:00:02 valhalla: hmmm Jul 02 10:00:13 hi all Jul 02 10:00:59 i'm having a problem with all recipes that require u-boot, i can't fetch u-boot anymore :( Jul 02 10:04:32 valhalla: agree ... fetching is manually gives the correct checksum Jul 02 10:06:21 thebohemian: ping Jul 02 10:06:36 http://goddchen.pastebin.com/m65f8304f Jul 02 10:06:39 any ideas? Jul 02 10:06:40 what is wrong? Jul 02 10:08:04 hrw: I am out to lunch - I'll pong you later Jul 02 10:08:38 thebohemian: ok, I have a patch fro classpath for review Jul 02 10:12:15 valhalla: glibc 2.6.1 seems to work ok for me. I'll try 2.9. Jul 02 10:15:42 pb_: I can try 2.6.1, I was just using the default Jul 02 10:19:44 morning Jul 02 10:23:47 does anybody have an idea why i can't fetch u-boot-git? Jul 02 10:25:49 Goddchen: bad url? **** BEGIN LOGGING AT Thu Jul 02 10:34:15 2009 Jul 02 10:43:03 valhalla: I do see that same get_pc_thunk error with 2.9. looking at the code it seems that it will probably build for i686 but not for i586 as it stands. Jul 02 10:44:52 pb_: sounds likely, but I have no clue on possible fixes Jul 02 10:45:15 2.6.1 has just finished compiling with success, btw Jul 02 10:49:00 valhalla: I think it's probably just a case of making dl-tlsdesc.S use SETUP_PIC_REG(). Jul 02 10:49:27 where aclocal searches for its m4 files? Jul 02 10:50:28 I get "aclocal: acinclude.m4:639: file `qt.m4' does not exist" when "aclocal -I m4 -I /home/booxter/projects/oe.devel//tmp/work/armv7a-angstrom-linux-gnueabi/unixODBC-2.2.14-r0/unixODBC-2.2.14/m4/ -I /home/booxter/projects/oe.devel//tmp/staging/armv7a-angstrom-linux-gnueabi/usr/share/aclocal-1.10 -I /home/booxter/projects/oe.devel//tmp/staging/armv7a-angstrom-linux-gnueabi/usr/share/aclocal --force" is run by autoreconf Jul 02 10:51:18 qt.m4 is in /home/booxter/projects/oe.devel//tmp/work/armv7a-angstrom-linux-gnueabi/unixODBC-2.2.14-r0/unixODBC-2.2.14/m4/ Jul 02 10:51:26 booxter: see the fine manual Jul 02 10:51:32 http://sources.redhat.com/automake/automake.html#Macro-Search-Path Jul 02 10:53:19 pb_: then I don't get what's the problem with my recipe... Jul 02 10:53:21 fucking handylink Jul 02 10:55:09 Hello! I can't run any x86 or qemux86 images of angstrom on any PC... Could you give me working x86 filesystem image? Jul 02 10:55:38 booxter: well, based on the error message you pasted, it sounds like your acinclude.m4 file is broken. Jul 02 10:56:32 I don't think this is actually anything to do with the aclocal search path. Jul 02 10:57:01 fpga: what is broken? Jul 02 10:57:02 pb_: it has m4_include([qt.m4]) in the line 639 Jul 02 10:57:26 it hangs when starting filesystem Jul 02 10:57:43 I can even see angstrom logo on display with progress bar Jul 02 10:57:59 when it almost fileed - it stops Jul 02 10:58:54 fpga: switch by hand to VT1 (ALT+F1) Jul 02 10:59:02 fpga: well, using root= and rw as options Jul 02 10:59:11 * zecke_ built a x86 uclibc image yesterday Jul 02 10:59:14 and it boots with kvm Jul 02 10:59:34 but now I need at least console image working... Jul 02 10:59:39 rw? Jul 02 10:59:50 I'm using RO - it;s wrong? Jul 02 11:00:32 fpga: it depends, it will not fsck/remount (at least micro-image and minimal-image don't) Jul 02 11:01:48 ok Jul 02 11:04:44 am i the only one getting errors fetching u-boot-git? Jul 02 11:10:23 booxter: yeah, that's probably bogus. What happens if you delete that line? Jul 02 11:13:41 pb_: I just edited it from m4_include to include - seems to work now :) Jul 02 11:14:04 * * OE Bug 5279 has been created by pascal_kesseli(AT)hotmail.com Jul 02 11:14:06 * * glibc 2.2.5 : "can't resolve '_GLBOAL_OFFSET_TABLE_' Jul 02 11:14:08 * * http://bugs.openembedded.org/show_bug.cgi?id=5279 Jul 02 11:32:09 What is a good "starting-point" for building an image for a new board based in the e300 powerpc ? Jul 02 11:38:23 http://goddchen.pastebin.com/m65f8304f <- any ideas on this one? Jul 02 11:38:29 can't fetch u-boot-git anymore :( Jul 02 11:38:51 Goddchen: there's no point asking the same question again and again. Jul 02 11:47:49 opkg is terribly broken ;( Jul 02 11:48:13 it was done by OM.... corporate policy Jul 02 11:48:56 "opkg upgrade" on sheevaplug exits with segfault due to big number of packages to upgrade Jul 02 11:49:18 and this is not 'not enough memory' type of error Jul 02 11:49:27 was ipkg better in that matter? Jul 02 11:49:49 dos1: never used with big amounts Jul 02 11:50:01 on sheeva I am upgrading all packages now Jul 02 11:50:14 hrw: it's segfault and it's caused by running out of memory... Jul 02 11:50:52 dos1: total used free shared buffers cached Jul 02 11:50:52 Mem: 514384 99024 415360 0 0 69012 Jul 02 11:51:08 dos1: 400MB free ram is not 'out of memory' Jul 02 11:51:17 hrw with, or without opkg? :P Jul 02 11:51:22 during Jul 02 11:51:34 hmm Jul 02 11:51:37 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND Jul 02 11:51:37 6059 root 20 0 17852 15m 1200 R 59.0 3.1 0:11.87 opkg Jul 02 11:52:06 why aren't we using another package manager? Jul 02 11:53:03 the famous question Jul 02 11:53:15 opkg was meant to fix ipkg bugs. but it added some new ones Jul 02 11:54:18 but noone is working on opkg now... Jul 02 11:54:21 and removed some features while added not useful ones Jul 02 11:54:26 dos1: neither on ipkg Jul 02 11:54:56 yep Jul 02 11:55:23 dpkg+apt would be overkill for 64MB devices with small rootfs Jul 02 11:56:25 but opkg is really bad for that devices :/ Jul 02 11:56:39 64MB and some big upgrade = fail Jul 02 11:57:07 it's strange that noone is fixing that bugs Jul 02 11:57:24 everyone complains, everyone uses it, but noone fixes it :/ Jul 02 11:57:41 I am not a programmer Jul 02 11:57:50 //usr/lib/opkg/info/dropbear.postinst: line 7: update-rc.d: not found Jul 02 11:57:53 //usr/lib/opkg/info/dropbear.postinst: line 8: update-alternatives: not found Jul 02 11:57:56 argh Jul 02 11:58:09 it wasn't about you specifically :P Jul 02 11:58:13 hrw: screen session? Jul 02 11:58:22 no Jul 02 11:58:28 hmm Jul 02 11:58:30 strange Jul 02 12:04:24 03Holger Hans Peter Freyther  07org.openembedded.dev * r08e6f46442 10openembedded.git/recipes/util-linux-ng/ (files/uclibc-compile.patch util-linux-ng_2.15.bb): Jul 02 12:04:24 util-linux-ng: Fix compile of 2.15 for uclibc Jul 02 12:04:24 Unconditionally include stdarg.h to introduce va_list to Jul 02 12:04:24 the compiler. uclibc has langinfo but not these kind of Jul 02 12:04:24 attributes. Guard the usage of these attribute similar to Jul 02 12:04:25 how the uclibc locale test program is doing it. Jul 02 12:04:34 03Holger Hans Peter Freyther  07org.openembedded.dev * ra2f5d1f087 10openembedded.git/recipes/uclibc/uclibc-0.9.30.1/x86/uClibc.machine: (log message trimmed) Jul 02 12:04:34 uclibc: Add x86/uClibc.machine for x86 uClibc config Jul 02 12:04:34 Currently each MACHINE needs a uClibc.machine config otherwise Jul 02 12:04:36 the uClibc compile will fail with weird error messages. Add a Jul 02 12:04:38 config for MACHINE="x86" and "suprisingly" it is almost the same Jul 02 12:04:40 as the qemux86 version. I sent an email asking for help to Jul 02 12:04:42 handle this duplication. Jul 02 12:04:53 *weee* Jul 02 12:04:59 zecke_: :) Jul 02 12:05:03 morning all Jul 02 12:05:21 :) Jul 02 12:06:39 zecke_: I'm still meaning to look at your patches :/ Jul 02 12:06:56 I also have a queue of my own patches I haven't reviewed yet Jul 02 12:08:55 RP: bitbake? take your time. i have to build some confidence too :) Jul 02 12:09:04 zecke_: yes, the bitbake ones Jul 02 12:09:37 hi zecke Jul 02 12:11:32 the great thing is, they are really bisectable... I used that when messing up things Jul 02 12:12:10 anyone here to ack/review a minimal-uclibc.conf change? Jul 02 12:13:30 opkg kills PATH ;( Jul 02 12:14:07 zecke_: Thats cool :) Jul 02 12:15:44 oh and actually I built my uclibc images with a patched copy Jul 02 12:18:25 zecke_: I don't think minimal{-uclibc} really has a maintainer, but I can look at your patch if you want. Jul 02 12:19:13 pb_: it dumps uclibc to 0.9.30.1 like micro-uclibc Jul 02 12:19:28 pb_: so, should we nuke minimal? :) Jul 02 12:20:01 has anyone ever used bootimhg? I wonder how to create a image for virtualbox... Jul 02 12:20:11 zecke_: I suspect we probably should. I don't think minimal is serving any very useful purpose at the moment. Jul 02 12:20:44 zecke_: right now, minimal is basically just a de-branded angstrom and I don't think this is necessarily something that anybody wants. Jul 02 12:20:44 pb_: minimal -> micro? Jul 02 12:22:11 okay, will send a patch then Jul 02 12:22:37 zecke_: yeah, I think micro has probably taken over some of the use cases for minimal. There is still a gap in the distro ecosystem for a third distro between angstrom and micro, but it (a) probably shouldn't be called "minimal", and (b) probably doesn't have much in common with today's minimal in implementation terms either. Jul 02 12:22:59 the old name of "generic" was probably better and we could revive that if nobody can think of something better. Jul 02 12:23:44 I guess this would be a good subject to discuss at some putative OEDEM :-} Jul 02 12:25:49 zecke_: on that subject, you should fill in the poll for the oedem date Jul 02 12:26:41 pb_: nice switch of subjects Jul 02 12:27:23 zecke pasted "upgrade uclibc" at http://paste.lisp.org/display/82897 Jul 02 12:27:35 pb_: this is my local change, I think it can't hurt Jul 02 12:27:41 lisppaste7: thanks Jul 02 12:27:54 zecke_: that looks like a fine change Jul 02 12:28:03 Acked-By? thanks Jul 02 12:28:10 yeah, go ahead Jul 02 12:28:11 ~curse opkg Jul 02 12:28:12 May you be reincarnated as a Windows XP administrator, opkg ! Jul 02 12:28:21 I will ask to kill minimal later today (hopefully) Jul 02 12:28:46 okay, cool Jul 02 12:29:41 I think überhacker mickeyl was the last person to work on minimal in a significant way, you might want to get his opinions on that. Jul 02 12:30:14 pb_: rigth, with my current pov, I think mickeyl's aim is to have a unbranded angstrom? :} Jul 02 12:30:34 I just wonder what for Jul 02 12:31:36 zecke_: I think his original aim was just to have a credible distro that wasn't angstrom, rather than a de-branded angstrom specifically. Jul 02 12:32:06 03Holger Hans Peter Freyther  07org.openembedded.dev * r9c3ffea91c 10openembedded.git/conf/distro/minimal-uclibc.conf: Jul 02 12:32:06 minimal-uclibc: Upgrade uclibc to 0.9.30.1 Jul 02 12:32:06 Catch up with micro-uclibc.conf by upgrading uclibc. I will Jul 02 12:32:06 spawn a discussion about the future of minimal(-uclibc) in the Jul 02 12:32:07 presence of micro(-uclibc). Jul 02 12:32:07 fair enough Jul 02 12:32:11 Acked-By: Phil Blundell Jul 02 12:37:47 I've been thinking occasionally about creating a new generic-type distro for myself, but so far I've never really been able to find the time to work on it properly. I do think something like that would be worth having: it'd fill approximately the same market niche as the old familiar, I guess. Jul 02 12:39:08 pb_: maybe I'm too ignorant? what is the niche/market here? Jul 02 12:41:14 zecke_: well, basically somewhere midway between micro and angstrom: recognisably unix, with at least some concessions to shell use, but still "embedded" in flavour rather than a desktop-type experience. Jul 02 12:42:12 hi mickeyl Jul 02 12:42:14 yo Jul 02 12:42:18 g'day mickeyl Jul 02 12:42:22 hi pb_ Jul 02 12:42:30 i see you folks want to kill my distro again? :D Jul 02 12:42:35 and again Jul 02 12:42:42 * hrw wants to kill opkg Jul 02 12:43:03 minimal went through a focus reorientation Jul 02 12:43:12 but for that I have to stand in long queue ;( Jul 02 12:43:32 zecke_: send the mail and I'll comment on that Jul 02 12:43:42 might be better than just to discuss it here Jul 02 12:43:54 good plan Jul 02 12:45:25 zecke_: still waiting for your address, btw.! Jul 02 12:45:35 how long will you be in Essen? Jul 02 12:46:07 mickeyl: i will be back on the 8th Jul 02 12:46:35 hmm Jul 02 12:46:40 ok, then we need to be quick Jul 02 12:46:46 else the parcel will arrive when you're back Jul 02 12:46:57 mickeyl: sent Jul 02 12:47:16 mickeyl: oh well... no way I can get the letter tomorrow :) Jul 02 12:47:40 i'll bring it to the post later today, need to buy bread anyways Jul 02 12:47:47 should be there on saturday Jul 02 12:47:53 oh the irony Jul 02 12:47:59 i have a shiny v-piano now Jul 02 12:48:04 looks like it is time to check dpkg+apt and forget that opkg exists Jul 02 12:48:05 but no time for 10 days to even unpack it Jul 02 12:48:07 *sigh* Jul 02 12:48:18 mickeyl: poor boy Jul 02 12:48:21 indeed Jul 02 12:48:50 pleasant anticipation can mutate into frustration if the time span is too long ;) Jul 02 12:49:16 has anyone built an x86 image that is usable in virtualbox? Jul 02 12:49:31 zecke_: palm did Jul 02 12:49:50 hrw: how? which bootloader? Jul 02 12:49:56 * florian too Jul 02 12:50:00 zecke_: grub on cdrom Jul 02 12:50:22 florian: which bootloader? syslinux? grub? Jul 02 12:50:44 zecke_: Poky creates working hdd and iso images with syslinux Jul 02 12:51:07 zecke_: grub iirc... that was for the gpephone project. but syslinux might be easier. Jul 02 12:51:07 hrw: how? do I need to INHERIT += syslinux or bootimg? or something special? Jul 02 12:51:20 bootimg Jul 02 12:51:44 zecke_: system was used as initrd iirc Jul 02 12:53:47 hrw: inherit where? INHERIT += "bootimg" in local.conf? Jul 02 12:54:36 yes Jul 02 12:54:59 zecke_: sorry, no Jul 02 12:55:10 *confused* :) Jul 02 12:55:32 zecke_: http://pastebin.ca/1481846 is recipe Jul 02 12:55:34 for image Jul 02 12:56:43 hrw: thanks Jul 02 12:57:14 * zecke_ attempts to build a minimal browser image Jul 02 12:58:03 zecke_: micro-image + dillo? :) Jul 02 12:58:42 no, a sane browser engine :) Jul 02 12:58:55 w3m? Jul 02 12:58:57 netsurf! Jul 02 12:58:58 * zecke_ saw fltk in a product recently... Jul 02 12:59:13 zecke_: really? Jul 02 13:00:14 florian: yeah! fltk on microwindows Jul 02 13:00:27 zecke_: cool Jul 02 13:06:08 bash-3.2# reboot Jul 02 13:06:08 shutdown: No such file or directory Jul 02 13:06:15 ~curse tick Jul 02 13:06:16 May the fleas of a thousand camels infest your most sensitive regions, tick ! Jul 02 13:06:36 oh Jul 02 13:07:00 hrw: that is not appropriate, at least he worked on it :) Jul 02 13:07:07 hrw: and o-hand was even paid to work on it :) Jul 02 13:08:50 http://marcin.juszkiewicz.com.pl/2009/07/02/embedded-package-managers-sucks/ Jul 02 13:09:33 zecke_: and I need to rebuild rootfs for sheevaplug from scratch due to a way how "opkg upgrade" worked Jul 02 13:17:06 Gnaa... are the new Angstrom compiler flags guilty for the terribly bloat of oe $TMPDIRs?! Jul 02 13:17:45 florian: I believe that there is some problem with rm_work Jul 02 13:18:10 valhalla: oh great :-/ Jul 02 13:18:50 using bitbake -c rm_work still works, using bitbake -c rm_work_all does it, but near the end of the build Jul 02 14:30:45 hello? Jul 02 14:31:13 is there anybody that could help me with a little problem? Jul 02 14:36:37 is there anybody that could help me with a little problem? Jul 02 14:36:37 when trying to execute Jul 02 14:36:37 git checkout origin/stable/bb -b stable/2009 Jul 02 14:36:37 the response is... Jul 02 14:36:37 fatal: git checkout: updating paths is incompatible with switching branches/forcing Jul 02 14:36:38 Did you intend to checkout 'origin/stable/bb' which can not be resolved as commit? Jul 02 14:36:40 any ideas? Jul 02 14:45:45 origin/stable/bb? Jul 02 14:45:59 try "git checkout origin/stable/2009 -b stable/2009" Jul 02 14:57:35 Gnutoo: did go got any progress? Jul 02 14:57:48 Gnutoo: at the routerboard stuff, i meant Jul 02 14:59:02 03Klaus Kurzmann  07shr/import * r6bb24cf2d7 10openembedded.git/conf/distro/include/shr-autorev-unstable.inc: Jul 02 14:59:02 shr-autorev-unstable: set frameworkd-config-shr to AUTOREV Jul 02 14:59:02 Signed-off-by: Klaus Kurzmann Jul 02 15:00:34 otavio, hi, yes and no Jul 02 15:00:47 Gnutoo: heh good Jul 02 15:01:00 otavio: tell me the yes part of it, plz? Jul 02 15:01:04 otavio, I didn't have much time but I cross-compiled uclibc with -g -ggdb3 and I did: Jul 02 15:01:40 chroot /bin/gdbserver 168.0.0.139:8022 /bin/hello Jul 02 15:02:08 and I get the problem with the point whree there is a problem in: Jul 02 15:02:11 *the source code Jul 02 15:02:17 *also in assembly mode Jul 02 15:02:37 Gnutoo: I and mario-goulart were pondering ig it couldn't be a gcc flaw Jul 02 15:02:41 now when I'll have time I'll try to understand what's wrong Jul 02 15:03:06 Gnutoo: did you send the code place to mario-goulart ? Jul 02 15:03:15 otavio, basically it jumps to a location that is outside the bounds of the segmented memory...and it segfault Jul 02 15:03:36 otavio, mario-goulart has evrything Jul 02 15:03:50 otavio, assembly in pastebin and source code in mail Jul 02 15:04:02 Gnutoo: in this case i think it could be two things: Jul 02 15:04:06 Gnutoo: gcc bug Jul 02 15:04:14 Gnutoo: binutils bug Jul 02 15:04:19 ok Jul 02 15:04:27 Gnutoo: what do you think? Jul 02 15:04:35 otavio: http://pastebin.com/m218aa87 Jul 02 15:04:38 otavio: http://pastebin.com/m7fbbad85 Jul 02 15:04:45 I don't know...I didn't have time to look at the source of the debug thing yet Jul 02 15:04:53 I produced it but had to sleep Jul 02 15:05:33 * mario-goulart leaves to have lunch Jul 02 15:05:40 it segfault while executing jalr t9 Jul 02 15:06:10 and contained a location that I gave on irc Jul 02 15:06:41 otavio, by the way how did you get the idea of porting openwrt to openembedded? Jul 02 15:07:37 Gnutoo: well since openwrt works on the board Jul 02 15:07:48 Gnutoo: the most logical way to get it working is to compare both Jul 02 15:07:59 Gnutoo: so we reduce the amount of work we'd need to do in the oe Jul 02 15:08:16 Gnutoo: for me it is the most logical way of working in this kind of problem Jul 02 15:08:44 Gnutoo: i only try to go very deeply in debugging if i can't find any project that has it solved before Jul 02 15:09:06 Gnutoo: otherwise i try to look at what they have change to got it right Jul 02 15:10:23 ok Jul 02 15:11:15 Gnutoo: well, i don't know mips assembly so i'll probably can't help reading it now Jul 02 15:11:18 Gnutoo: heh Jul 02 15:11:31 I know a little bit mips assembly Jul 02 15:11:43 one year ago I learned it Jul 02 15:11:52 Gnutoo: good; so please look at it when you can :-) Jul 02 15:11:56 ok Jul 02 15:11:56 Gnutoo: it could help a lot Jul 02 15:12:52 Gnutoo: mario-goulart is going to look if there's anything interesting in gcc on openwrt today Jul 02 15:13:01 ok Jul 02 15:13:04 Gnutoo: i guess it could be the cause of it Jul 02 15:14:01 while I know a little bit mips assembly I don't know well GNU/Linux dynamic libraries system...I know it a little bit but I bet it's not enough to debug that Jul 02 15:15:14 Gnutoo: heh Jul 02 15:15:36 I have to find out how it works at the assemlby level Jul 02 15:16:06 khem: zecke: Hey, I think I may have figured out why my kubuntu bitbake was failing yesterday. I had to add a second volume for enough space to set up OE. I had the new volume mounted at /mnt/oebuild, and my $HOME/oe was a symlink to /mnt/oebuild/bbender. I changed it so that volume is directly mounted at $HOME/oe, and I'm already past the point where the m4-native build barfed for me before (GNUmakefile was symlinked to itself); I suspect it's probably going t Jul 02 15:18:25 otavio: yah, it could be a gcc bug, or a binutils bug, or a uclibc bug. only way to find out which is to inspect the broken code, unfortunately. Jul 02 15:18:52 mmm....maybe it's the relocation code or table that has problems Jul 02 15:19:15 in the asm code there are operations about the global pointer Jul 02 15:19:38 if I had to guess, I would say that uclibc was the most likely of the three to be broken, but you never know. Jul 02 15:20:22 yes it seems so because: Jul 02 15:20:26 g'day kergoth Jul 02 15:20:35 *running hello world on the openwrt rootfs works Jul 02 15:20:42 hey Jul 02 15:20:45 hello world was generated with oe's compiler Jul 02 15:21:23 *hello world doesn't work in oe's rootfs Jul 02 15:21:58 oh dear, invasion of the multiple kergoths again Jul 02 15:23:13 here's the source code with comments: http://pastebin.com/m80ff406 Jul 02 15:23:24 it says: Jul 02 15:24:16 Locate the global offset table. Since this code must be PIC we can take advantage of the magic offset register, if we happen to know what that is for this architecture. If not, we can always read stuff out of the ELF file to find it... Jul 02 15:24:25 and after that comment there is: Jul 02 15:24:37 DL_BOOT_COMPUTE_GOT(got); Jul 02 15:24:54 and what does DL_BOOT_COMPUTE_GOT() do for mips? Jul 02 15:25:07 and just after that: Now, finally, fix up the location of the dynamic stuff Jul 02 15:25:10 don't know Jul 02 15:25:28 so I bet it's for relocation Jul 02 15:25:37 but I don't know more... Jul 02 15:25:53 maybe I should look at the assembly of DL_BOOT_COMPUTE_GOT Jul 02 15:26:11 and it's at: Jul 02 15:26:15 ldso/ldso/dl-startup.c:195 Jul 02 15:26:21 so it's realy the relocation Jul 02 15:28:50 well, what does the source for DL_BOOT_COMPUTE_GOT say in this case? Jul 02 15:29:02 probably best to look at that before the assembler output :-) Jul 02 15:29:26 that's what I'm doing right now Jul 02 15:29:39 righto Jul 02 15:31:56 http://pastebin.com/m73213507 Jul 02 15:32:11 I'll look for elf_machine_dynamic Jul 02 15:35:42 http://pastebin.com/m4eacbd81 Jul 02 15:35:54 okay Jul 02 15:36:01 so, that shouldn't require any function calls at all Jul 02 15:36:16 if it's crashing there, it sounds like gcc is failing to inline those functions for some reason. Jul 02 15:36:39 try inspecting the object files (and/or assembly output) and see if they have indeed been inlined. Jul 02 15:39:15 ok Jul 02 15:39:22 thanks a lot Jul 02 15:43:08 03Marcin Juszkiewicz  07org.openembedded.dev * r33e3a38aa1 10openembedded.git/recipes/classpath/ (classpath.inc classpath_0.98.bb files/fix-gmp.patch): classpath: depend on gmp (for libjavamath) and do not use system one Jul 02 15:49:08 lol what's that: patches-0.9.29/150-fix-ldso-text-realloc-segfault.patch: ? Jul 02 15:54:57 pb_, how do I verify that the function is inlined...is there an easy way or should I go trough the assembly and look if it tried to call a function(so there would be traces of saving the registers etc...) Jul 02 15:55:20 pb_, ah ok sorry Jul 02 15:59:39 ok with objdump it's easy Jul 02 16:12:31 hello, anyone could help me with a problem Jul 02 16:15:30 hi bangan Jul 02 16:15:38 hi Jul 02 16:15:55 i have a problem after downloading oe metadata from git Jul 02 16:16:34 just after downloading, when I issue the command git checkout origin/stable/2009 -b stable/2009 Jul 02 16:16:37 the answer is.. Jul 02 16:16:46 error: You have local changes to 'recipes/irrlicht/files/irrlicht_beagle.diff'; cannot switch branches. Jul 02 16:16:49 why that? Jul 02 16:20:04 bangan: the message is pretty clear - git diff shows the changes Jul 02 16:20:36 bangan: if you changed it by accident you can just overwrite changes by git checkout Jul 02 16:28:08 Gnutoo: right, objdump is probably the easiest way Jul 02 16:28:19 ok Jul 02 16:31:04 pb_, maybe also using Winline Jul 02 16:32:21 possibly, but objdump would be the definitive check Jul 02 16:32:32 Winline might be unreliable if the problem is due to a gcc bug in the first place Jul 02 16:32:42 ok Jul 02 16:37:51 Gnutoo: got anything? Jul 02 16:37:57 pastbining Jul 02 16:40:16 Gnutoo: did the uclibc patch, from openwrt, been tested? Jul 02 16:40:21 Gnutoo: the 150-...? Jul 02 16:40:26 no Jul 02 16:40:35 but it's for 29 and we use 30.1 Jul 02 16:40:49 openwrt hasn't addied it again for 30.1 Jul 02 16:41:16 http://pastebin.ca/1482059 Jul 02 16:41:26 http://www.pastebin.ca/1482067 Jul 02 16:41:55 moreover the 150 doesn't seem to touch the same code than the part where there is the problem Jul 02 16:41:59 I'll pastebin it too Jul 02 16:42:42 http://www.pastebin.ca/1482069 Jul 02 16:42:57 but it's in the same source file Jul 02 16:45:26 Gnutoo: the code itself is unreadable for me Jul 02 16:45:34 ah sorry Jul 02 16:45:38 Gnutoo: i can't understand that asm code :P Jul 02 16:46:06 Gnutoo: but from what you read on that it looks to be a fault of what? uclibc itself? Jul 02 16:46:07 how do I know if it has been inlined...I never looked at the assembly of an inline function...should I try a test C code? Jul 02 16:46:18 otavio, from the debug session Jul 02 16:46:31 otavio,it segfault in ld-uclibc.so Jul 02 16:47:00 florian: continues the problem making a checkout :S Jul 02 16:47:04 Gnutoo: and you've tested it at openwrt chroot right? Jul 02 16:47:15 Gnutoo: and it works, the binary I mean Jul 02 16:47:25 bangan: same file? Jul 02 16:47:29 otavio, in both openwrt's rootfs(ok) and oe's chroot(segfault ) Jul 02 16:47:33 yes same file Jul 02 16:47:38 oops Jul 02 16:47:51 Gnutoo: did you try to copy the uclibc so to oe chroot and give it a try? Jul 02 16:48:05 I'll try Jul 02 16:48:10 Gnutoo: if it works, you might use ltrace to see what it calls before died Jul 02 16:48:16 uclibc-ld.so or the whole tring Jul 02 16:48:17 Gnutoo: before die Jul 02 16:48:19 ok Jul 02 16:48:25 Gnutoo: the so only Jul 02 16:48:29 I didn't though of ltrace Jul 02 16:48:32 I'll try it Jul 02 16:49:04 ah wow...ltrace should show if it's inlined Jul 02 16:49:20 Gnutoo: heh :-) Jul 02 16:49:29 if it sows a call it's not inlined but if it doesn't show anything it is Jul 02 16:54:32 Gnutoo: cool Jul 02 16:54:35 otavio, chroot /mnt/NFS with openwrt's ld-uClibc.so.0 works fine Jul 02 16:55:15 I must cross-compile a static ltrace with oe now Jul 02 16:55:20 or with openwrt Jul 02 16:55:35 Gnutoo: WOW so it is indeed in uclibc Jul 02 16:55:43 ok Jul 02 16:55:54 but it may be something that is not inlined like you told Jul 02 16:56:09 mario-goulart, tried openwrt's patches on uclibc Jul 02 16:56:17 Gnutoo: it MIGHT be the -PIE option Jul 02 16:56:19 Gnutoo: on gcc Jul 02 16:56:20 mario-goulart, same result...doesn't work Jul 02 16:56:21 ok Jul 02 16:56:39 ok I'll loook Jul 02 16:57:48 Gnutoo: how are you testing it? are you using qemu for the tests? Jul 02 16:57:55 no real router Jul 02 16:57:56 Gnutoo: or are you using the real hw? Jul 02 16:58:01 yes real hardware Jul 02 16:58:08 Gnutoo: but you're using nfs for it Jul 02 16:58:18 I use an x86 router so my old router is an oe toy now Jul 02 16:58:22 yes and no Jul 02 16:58:28 NFS is used for chrooting Jul 02 16:58:35 or with oe's kernel Jul 02 16:58:41 but actually I use: Jul 02 16:58:44 boot on openwrt Jul 02 16:58:56 and mount NFS root for chrooting inside it Jul 02 16:59:33 Gnutoo: so you don't need to reboot it all the time Jul 02 16:59:41 Gnutoo: good catch Jul 02 16:59:54 so I don't need to buy a second serial usb port Jul 02 17:00:13 Gnutoo: it is indeed a nice way to get it working in a easy to debug way .. indeed Jul 02 17:00:16 yes Jul 02 17:00:31 because otherwise there is the following setup: Jul 02 17:00:57 init=gdbserver ... Jul 02 17:01:12 s/gdbserver/bin\/gdbserver Jul 02 17:01:20 florian: ok, right now, but when trying to make the images, bitbake answers: Jul 02 17:01:20 : No such file or directory Jul 02 17:01:20 with all invocations, even only "bitbake" Jul 02 17:01:20 my $PATH: /media/beagleboard/openembedded/bitbake/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games (/media/beagleboard is a partiton specially for BB devel) Jul 02 17:09:26 ¿? Jul 02 17:11:21 ~seen likewise Jul 02 17:11:22 likewise was last seen on IRC in channel #oe, 8d 20h 2m 27s ago, saying: 'Gnutoo: ok, just checking :-)'. Jul 02 17:24:01 Gnutoo: that does look like it hasn't been inlined. if you add __attribute__ ((always_inline)), does that help? Jul 02 17:24:17 ok I'll try Jul 02 17:26:38 by the way does ltrace work for uclibc? Jul 02 17:26:59 | make -C sysdeps/linux-uclibc | make: *** sysdeps/linux-uclibc: No such file or directory. Stop. Jul 02 17:27:13 I'll try the attribute Jul 02 17:27:39 I'm not sure if ltrace supports uclibc or not, but it certainly won't help for this issue. Jul 02 17:28:00 your program is crashing too early, the dynamic linker isn't even started yet. Jul 02 17:29:49 ok Jul 02 17:31:11 <_recipe_> hello Jul 02 17:31:23 <_recipe_> anyone know about this error, while building base-image? Jul 02 17:31:25 <_recipe_> ERROR: function staging_helper failed Jul 02 17:31:25 <_recipe_> ERROR: see log in /media/beagleboard/angstrom-dev/work/i686-linux/gnu-config-native-0.1+cvs20050701-r5/temp/log.staging_helper.9718 Jul 02 17:33:13 _recipe_: did you do as it suggests and see the log? Jul 02 17:36:20 wow...http://pastebin.com/m65bb4287 Jul 02 17:37:21 more complete log here: http://pastebin.com/m1df523ee Jul 02 17:37:34 doh! Jul 02 17:37:40 I wonder why it thinks that function isn't inlinable. Jul 02 17:38:32 I wonder what it meant by "sorry, unimplemented:" Jul 02 17:39:01 that means that gcc knows the failure is due to its own deficiencies rather than user error. Jul 02 17:41:23 ok Jul 02 17:42:44 you could try converting those functions to be macros instead, that way they must be inlined. Jul 02 17:43:19 ok Jul 02 17:43:35 but I bet the best way is to fix gcc or to find the good patch Jul 02 17:44:32 FWIW, I'll throw in here that I am a user of the minimal distro. And I fixed things that are within my power to understand. I'd like to have something not-Angstrom and not-micro to continue to exist. Jul 02 17:45:00 The idea to build virtualbox images with OE sounds intriguing. Another option besides qemu. Jul 02 17:48:44 Does OE allow one to have multiple builds (different builds, not the same build for diff. machines) running at the same time using the same OE recipe tree ? Jul 02 17:49:30 oespirit: the same recipes, yes. the same tmp dir wouldn't be advisable, though Jul 02 17:49:32 I am almost sure it doesnt, since there can be only one local.conf at a time, but was wondering if there was an option I was missing out on ? Jul 02 17:49:55 local.conf is normally put in your build dir, not the OpenEmbedded repository Jul 02 17:50:01 kergoth: different tmpdirs are ok with me. Jul 02 17:50:06 kergoth: oh ok. Jul 02 17:50:17 which is why all the instructions, guides, manuals advise using one Jul 02 17:50:44 kergoth: I am sorry, I was mistaken. I have been working with my local conf in the default place, openembedded/conf Jul 02 17:50:52 "default place"? Jul 02 17:50:57 kergoth: thanks a lot. simplifies things for me Jul 02 17:51:23 kergoth: where the local.conf.sample is kept. under ${OEBASE}/openembedded/conf/ Jul 02 17:51:24 bitbake looks for its files anywhere in BBPATH. if you put a build directory as the first entry in bbpath, it will find your local.conf there. Jul 02 17:51:27 yes, it is Jul 02 17:53:55 kergoth: thanks again :) . will try this out Jul 02 17:54:05 np Jul 02 17:54:45 make a build dir with a conf/local.conf, add build dir to the front of BBPATH, and either run builds there or force TMPDIR to the /tmp, and you should be good to go Jul 02 18:26:26 Gnutoo: looking at your log I'm pondering how openwrt managed to compile it right Jul 02 18:26:35 ok Jul 02 18:27:05 -fPIC is on...there are things about that in the changelog of uclibc Jul 02 18:27:20 Gnutoo: in OE or OpenWRT? Jul 02 18:27:32 oe Jul 02 18:27:39 Gnutoo: and owrt? Jul 02 18:27:46 mario-goulart: ? Jul 02 18:28:06 otavio: let me check Jul 02 18:28:29 mario-goulart: it would be nice to check the OpenWRT build log and see the full list of CFLAGS used Jul 02 18:28:44 mario-goulart: I guess it could be using -fPIE Jul 02 18:28:45 otavio: just checked. I'm using the same. Jul 02 18:29:18 mario-goulart: and in your build do you have same error then Gnutoo has? but unimplemented stuff Jul 02 18:29:39 otavio: no. No errors. Jul 02 18:29:53 otavio, maybe he didn't try that: Jul 02 18:30:17 otavio, Gnutoo: both OE and OWrt have this: STAGE1_CFLAGS=-g -fkeep-inline-functions, regarding to inlining. Jul 02 18:30:32 (gcc) Jul 02 18:30:35 ok Jul 02 18:30:43 mario-goulart: ok but in the compilation log? Jul 02 18:30:56 otavio: In the Makefile. Jul 02 18:30:57 mario-goulart: it might mangle it when doing uclibc Jul 02 18:31:02 yes it does Jul 02 18:31:11 it mangle every flag you pass to it Jul 02 18:31:17 you have to do it in the .config Jul 02 18:31:24 mario-goulart: yes but did you check in the log? Jul 02 18:31:53 mario-goulart: you might get it in the devshell and passing V=1 in make I guess Jul 02 18:32:47 otavio: haven't check the build log. Jul 02 18:33:01 otavio: uclibc, IIRC, has not devshell task Jul 02 18:33:23 mario-goulart: so I'd go for it. both in openwrt and oe. It could be the root of the problem Jul 02 18:33:39 Gnutoo: have you done it? Jul 02 18:33:49 mario-goulart, where is STAGE1_CFLAGS? Jul 02 18:33:56 otavio, have done what? Jul 02 18:34:17 otavio, if it's modifying the .config yes but only for -g -ggdb3 Jul 02 18:34:18 Gnutoo: compared both flags used in the build Jul 02 18:34:23 otavio, not yes Jul 02 18:34:26 Gnutoo: oe against owrt Jul 02 18:34:28 Gnutoo: in gcc's Makefile (from both OE and Owrt) Jul 02 18:34:40 ok Jul 02 18:37:18 Gnutoo: I'm checking Owrt's gcc-4.2.4-final dir. Jul 02 18:37:34 ok Jul 02 18:40:40 Gnutoo: how did you manage to get that uclibc build error? Some special flag? Jul 02 18:40:53 Gnutoo: I mean this error: http://pastebin.com/m1df523ee Jul 02 18:41:05 mario-goulart, no a patch Jul 02 18:41:28 Gnutoo: Hmmm. From owrt? Jul 02 18:41:42 no from irc Jul 02 18:42:10 http://pastebin.com/m1bac18f7 Jul 02 18:42:32 Gnutoo: thanks. Jul 02 18:42:49 mario-goulart, it forces inlining of the functions ... Jul 02 18:42:59 mario-goulart, because they should be inlined Jul 02 18:43:17 mario-goulart, but inlining fail with the error message you know Jul 02 18:43:40 Gnutoo: ok Jul 02 19:11:53 03Klaus Kurzmann  07shr/import * ra98fb0f0a9 10openembedded.git/recipes/shr/e-wm-theme-illume-shr_git.bb: Jul 02 19:11:53 e-wm-theme-illume-shr: depend on edje-native instead of edje Jul 02 19:11:53 and use ${STAGING_BINDIR_NATIVE}/edje_cc Jul 02 19:11:53 Signed-off-by: Klaus Kurzmann Jul 02 19:11:55 03Klaus Kurzmann  07shr/import * rb5218259ed 10openembedded.git/recipes/shr/e-wm-theme-illume-sixteen_git.bb: Jul 02 19:11:58 e-wm-theme-illume-sixteen: new recipe Jul 02 19:12:00 Signed-off-by: Klaus Kurzmann Jul 02 19:12:02 03Klaus Kurzmann  07shr/import * r35ec875db8 10openembedded.git/recipes/shr/elementary-theme-sixteen_git.bb: Jul 02 19:12:05 elementary-theme-sixteen: new recipe Jul 02 19:12:07 Signed-off-by: Klaus Kurzmann Jul 02 19:12:09 03Klaus Kurzmann  07shr/import * r2aec99c3c7 10openembedded.git/recipes/shr/etk-theme-shr_git.bb: Jul 02 19:12:12 etk-theme-shr: depend on edje-native instead of edje Jul 02 19:12:14 and use ${STAGING_BINDIR_NATIVE}/edje_cc Jul 02 19:12:16 Signed-off-by: Klaus Kurzmann Jul 02 19:14:00 03Stanislav Brabec  07org.openembedded.dev * r0514bb1d46 10openembedded.git/recipes/gnome/ (6 files): epiphany: iso-codes is a runtime dependency. Jul 02 19:21:08 pb_: ping Jul 02 19:35:14 03Klaus Kurzmann  07shr/import * r5051126db3 10openembedded.git/conf/distro/include/shr-autorev.inc: Jul 02 19:35:14 shr-autorev.inc: set e-wm-theme-illume-sixteen and elementary-theme-sixteen to AUTOREV Jul 02 19:35:14 Signed-off-by: Klaus Kurzmann Jul 02 19:55:15 hello? Jul 02 19:58:18 does anybody know about this error while building base-image? Jul 02 19:58:19 ERROR: '/home/tuilabs/oe/openembedded/recipes/quilt/quilt-native_0.46.bb' failed Jul 02 20:17:35 03Klaus Kurzmann  07shr/import * reea7bdde8f 10openembedded.git/recipes/shr/elementary-theme-sixteen_git.bb: Jul 02 20:17:35 elementary-theme-sixteen: fix install path Jul 02 20:17:35 Signed-off-by: Klaus Kurzmann Jul 02 20:22:45 tuilabs, we need more infos such as what came before ERROR: '/home/tuilabs/oe/openembedded/recipes/quilt/quilt-native_0.46.bb' failed but...in a pastebin please...if you don't know what a pastebin is just ask Jul 02 20:24:20 Gnutoo: the log says: /usr/bin/env: python Jul 02 20:24:20 : No such file or directory Jul 02 20:24:33 I don't know why it says that about python :S? Jul 02 20:24:37 tuilabs, mmm....did you install python Jul 02 20:24:52 I have python on my system, yes Jul 02 20:25:20 tuilabs, so I don't know...maybe check: Jul 02 20:25:27 *if you have /usr/bin/env Jul 02 20:25:49 *if you have all required python packages Jul 02 20:26:05 yes, I can call it Jul 02 20:26:11 and returns the list of env vars Jul 02 20:26:44 tuilabs, /usr/bin/env is for finding python...for instance freebsd system can have python in others place than /usr/bin/python Jul 02 20:27:49 and why should it fail :S? Jul 02 20:28:12 python is in /usr/bin/python Jul 02 20:34:31 tuilabs, do you have env ? Jul 02 20:34:49 yes, its in /usr/bin/env Jul 02 20:35:10 ok Jul 02 20:35:37 where does it points to (on my system /usr/bin/env is a symlink to env) Jul 02 20:35:41 oops Jul 02 20:35:45 where does it points to (on my system /usr/bin/env is a symlink to /bin/env) Jul 02 20:37:32 tuilabs, could you pastebin the log+the run script? by the way if you get no help here there is a mailing list Jul 02 20:37:37 1 moment Jul 02 20:37:40 ok Jul 02 20:39:19 this is the output (2nd run of bitbake) Jul 02 20:39:20 http://pastebin.com/m404906ba Jul 02 20:39:53 and all logs contain /usr/bin/env: python Jul 02 20:39:54 : No such file or directory Jul 02 20:39:54 /usr/bin/env: python Jul 02 20:39:54 : No such file or directory Jul 02 20:41:55 ok Jul 02 20:41:55 and /usr/bin/env is an executable Jul 02 20:42:59 ok I don't know sorry...try asking someone else... Jul 02 20:43:40 I've had a similar problem with bitbake, using the one in git from openembedded metadata Jul 02 20:44:17 and I had to download it from svn to get it working Jul 02 20:46:11 re Jul 02 20:58:31 mario-goulart, hi, any progress? Jul 02 20:58:53 hi Gnutoo Jul 02 20:59:01 Just new frustrations. :-) Jul 02 20:59:06 ah ok which ones? Jul 02 21:00:02 I've been trying to reproduce owrt build environment. So I've tried the same versions for binutils, uclibc and gcc. That haven't worked so far. Jul 02 21:00:28 I've also tried using similar CFLAGS for these packages, but no luck either. Jul 02 21:00:36 mario-goulart, ok I'll look Jul 02 21:00:49 mario-goulart, maybe using openwrt's compiler? Jul 02 21:00:56 mario-goulart, as an external compiler Jul 02 21:01:13 or disassembling both ld-uclibc.so Jul 02 21:01:28 Gnutoo: hmmm. That would be a good shot. Jul 02 21:01:39 which one of the 2 options? Jul 02 21:02:07 My latest attempt was to use gcc 4.3. I got and error and the recommendation for using -fPIC when compiling libgpg-error. Jul 02 21:02:13 ok Jul 02 21:02:25 Gnutoo: using owrt's compiler. Jul 02 21:02:30 ok Jul 02 21:02:43 I'll try disassembling both executables Jul 02 21:02:50 s/executables/libs Jul 02 21:04:14 OE and owrt share a bunch of patches for gcc 4.2.4. Jul 02 21:05:21 Gnutoo: do you know an easy way to make OE use the compiler from owrt build_dir? Jul 02 21:05:26 mario-goulart, ok...first mistery to solve: why the sections aren't displayed with a wrt binary? Jul 02 21:05:33 mario-goulart, yes Jul 02 21:05:42 mario-goulart, I'll find the howto Jul 02 21:06:23 mario-goulart, http://bec-systems.com/web/content/view/56/9/ Jul 02 21:06:29 Gnutoo: second mistery: why owrt doens't install libpthread even when those THREAD options set in the config files? Jul 02 21:06:40 mario-goulart, ok Jul 02 21:07:00 maybe we should ask in #openwrt...but before I'll retest with openwrt's binutils Jul 02 21:08:00 Gnutoo: Right now I'm taking a look at owrt's svn log to see if I can find something. Jul 02 21:08:07 ok Jul 02 21:08:38 I'll ask for the empty sections Jul 02 21:09:01 Right. Jul 02 21:09:15 There's something about segfaults involving uclibc at https://dev.openwrt.org/ticket/5242 Jul 02 21:10:33 ok Jul 02 21:20:39 jo Jul 02 21:21:52 mario-goulart, look at uclibc_ldso_use_O0.patch Jul 02 21:23:07 Gnutoo: -O0 Jul 02 21:23:13 mario-goulart, maybe we should compare the right Makefile...not the top ones Jul 02 21:23:49 that was in oe Jul 02 21:24:23 Gnutoo: I've tried BUILD_CFLAGS = '-O0', TARGET_CFLAGS = '-O0', CFLAGS = '-O0' in uclibc_0.9.30.1.bb without luck Jul 02 21:24:38 mario-goulart, ok I'll check this Jul 02 21:25:00 Gnutoo: let me check owrt's flags. Jul 02 21:25:14 ok Jul 02 21:27:43 Gnutoo: it seems that there's no explicit -O flag. Jul 02 21:27:50 yes Jul 02 21:27:55 maybe we could try that Jul 02 21:28:07 Does gcc falls back to -O0? Jul 02 21:28:17 Gnutoo: you mean remove the patch? Jul 02 21:28:23 I'll do it Jul 02 21:28:33 ok Jul 02 21:28:42 no faster: include openwrt's Makefile.in and compile it Jul 02 21:30:24 a part of the patch is needed Jul 02 21:31:31 ah yes we could remove the patch...i'll try Jul 02 21:35:33 ok doesn't work Jul 02 21:37:27 what a mistery. Jul 02 21:37:34 yes Jul 02 21:37:36 lol Jul 02 21:37:59 There's something magical being done by owrt build system. Jul 02 21:39:56 maybe we should ask in #wesnoth ...because they know well ELF and DWARF ? Jul 02 21:40:38 Gnutoo: or ask Ronnie James Dio about ELF's misteries. Jul 02 21:40:51 is he a writter? Jul 02 21:41:01 DWARF is the debugging format Jul 02 21:41:01 a singer Jul 02 21:41:03 ok Jul 02 21:41:11 Just a joke. :-) Jul 02 21:41:23 yes I understood Jul 02 21:41:31 mine was a joke too Jul 02 21:41:56 :-) Jul 02 21:43:51 kergoth: yo Jul 02 21:44:23 mario-goulart, http://gcc.gnu.org/ml/gcc/2005-06/msg01231.html Jul 02 21:44:41 mario-goulart, maybe we should try without -Os Jul 02 21:45:39 Gnutoo: IIRC, before I set CFLAGS on uclibc recipe, it was empty and OE was setting it to -O2. Jul 02 21:45:49 Then I tried -O0 Jul 02 21:45:51 mario-goulart, seems very similar with jalr t9 etc... Jul 02 21:46:05 mario-goulart, try -O1 Jul 02 21:46:29 Gnutoo: the description of the problem looks very familiar indeed Jul 02 21:46:38 mario-goulart, I've -Os in my flags Jul 02 21:46:59 mario-goulart, I saw it just before the compilation failure Jul 02 21:48:55 Gnutoo: do you explicitely set it as -Os? Jul 02 21:49:02 I don't remember Jul 02 21:49:04 I'll check Jul 02 21:49:43 ok Jul 02 21:50:15 pb__: damn, i completely forgot what i ping'd about :) Jul 02 21:52:09 kergoth: doh Jul 02 21:52:23 hi kergoth and pb Jul 02 21:52:41 hi woglinde Jul 02 21:53:05 hey woglinde Jul 02 21:53:19 I wonder where it comes from... Jul 02 21:53:22 maybe bitbake.conf Jul 02 21:53:24 I'll check Jul 02 21:54:03 I don't remember where I have set up that Jul 02 21:55:40 maybe in the distro include Jul 02 21:55:59 Gnutoo: if you didn't set the optimization explicitely, maybethe value comes from bitbake.conf's FULL_OPTIMIZATION Jul 02 21:56:12 no it's not there already checked Jul 02 21:56:30 ok Jul 02 21:57:32 Gnutoo: probably distro/include/sane-toolchain-uclibc.inc Jul 02 21:57:38 yes it's there Jul 02 21:58:48 Gnutoo: I have to go now. I'm gonna try to change this flag tomorrow and rebuild from scratch the whole thing. Jul 02 21:59:48 The -O1 thing looks promising, based on the message you found. Jul 02 21:59:51 mario-goulart, ok I'll try it now Jul 02 21:59:59 bye Jul 02 22:00:20 Ok. Bye. See you. Jul 02 23:32:33 I'm out of ideas. After being away from OE for many months, I just installed a fresh copy of everything. I run the first build "bitbake gpe-image" and it fails on the first do_compile, silently, the logfile is empty but bitbake insists that the compile failed. Jul 02 23:33:23 it is at shasum-native, it does produce a native executable "oe_sha256sum", running that will produce a sum on a file. Jul 02 23:33:57 anyone got any ideas where I could look for info? maybe get bitbake to be more expressive in the error? Jul 02 23:49:21 T0mW: I'd probably bitbake -c devshell shasum-native; then in the devshell, ../temp/run.do_compile. Jul 02 23:49:51 bitbake v1.8.10 works fine, v1.8.12 is broken Jul 02 23:50:14 the compile is clean, no errors. Jul 02 23:50:41 * kergoth does builds every day with 1.8.13 without problems Jul 02 23:52:10 kergoth: switching back to 1.8.12 to see if the binary it builds of shasum-native is bitwise the the same. Jul 02 23:53:13 oh, I'm using the 'stable/2009' branch Jul 02 23:55:58 odd, 'do_compile' will not run with v1.8.12, but recipe works fine with v1.8.10 Jul 03 02:42:40 hey guys Jul 03 02:42:46 anyone build libgles-omap3 recently? Jul 03 02:43:01 how come there is a .08 version which is higher than the one on the TI site? and do_accept_license fails here consistently Jul 03 02:47:39 is anyone working on this in some other branch with a fixed build or has updated instructions on how to get to the SDK (it's not listed under my extranets) **** ENDING LOGGING AT Fri Jul 03 02:59:57 2009