| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8
Comments:
<0> ibot: botsnack
<1> koen: :)
<2> yes i was thinking the same thing
<2> does anybody has experience with VFP?
<2> with the 3.4.4 csl gcc?
<0> giel_: real vfp or softvfp?
<2> i _think_ softvfp, but i'm not sure :S
<2> well, i use -mfloat-abi=soft because gcc was complaining it couldn't do hardfloat in combination with vfp
<3> is it just me, or is oe.pastebin.com not working properly?
<0> zwelch: it isn't
<0> zwelch: try rafb.net/paste
<3> yes, well... how can i tell bitbake to use it for 'pastelog'
<0> ehm....
<2> hm, let me try one more compile run, and if that doesn't work i'll tell elaborately what my problem is ;)
<3> heh
<3> well, i can hack it myself...
<3> but that presumes a compatible pastebin protocol (request/response)
<4> koen: hurry up with your SoC :-)
<0> :)
<0> XorA: I'm writing down a flowchart in my google notebook
<5> I must admit I'm looking forward to seeing the results of the SoC project :)
<0> hngr
<4> does glibc 2.3.5 build with binutils 2.17?
<3> koen, mickey|bbl: try this patch: http://rafb.net/paste/results/BVzqDk32.html
<3> incidentally, it was placed there by that patch :)
<3> hmmm
<4> koen: a day?
<2> okay, to come back to my problem
<2> | /home/oe/build/tmp/cross/lib/gcc/arm-linux/3.4.4/../../../../arm-linux/bin/ld: ERROR: /home/oe/build/tmp/cross/lib/gcc/arm-linux/3.4.4/libgcc.a(_ashldi3.o) uses FPA instructions, whereas /home/oe/build/tmp/work/glibc-intermediate-2.4-r5/build-arm-linux/elf/librtld.map.o does not
<2> lots of those
<0> giel: that means you switch params in the middle of a build
<0> switched*
<6> koen: i started a clean build
<0> hrm
<6> so, i have in my TARGET_CC_ARCH -mcpu=-march=armv5te -mtune=arm926ej-s -mfpu=vfp -mfloat-abi=soft
<0> shouldn't that be 'softfp' ?
<6> tried that, same effect
<0> right now you're telling gcc to use the vfp coprocessor
<0> ehm
<0> actually no
<6> source of the problem is that i'm not completely sure what i'm doing, i hate that ;(
<6> but i have to link against some libs i have here, which i compiled out of tree and they didn't compile without vfp
<6> and now my ffmpeg (in-tree) won't link against these libs if i compile it without vfp
<6> okay, i'll just fiddle on, if anyone has some great idea plz let me know ;)
<0> if all else fails: compile statically
<0> I suspect you might need some patches from crosstool/buildroot to get softvfp to work with gcc
<6> hmz
<6> might gcc 4.1 or something like that help?
<0> I sure hope so :)
<6> then i will also try to switch to that
<0> gcc 4.1.1 should have EABI (=softvfp) support
<0> so it should be able to handle sovftp without eabi as well
<6> but 3.4.4 csl should have as well, isn't it?
<0> no idea
<0> 3.4.4 csl == patched to hell
<6> hm
<6> true
<6> okay, that's on my to-try list then, using 4.1.1
<7> gm
<0> hey Crofton
<7> hi
<7> just back from Italy
<7> good vacation
<0> that's good to hear
<7> I like the kids playgrounds in beer gardens in Germany :)
<7> need to tell my friends with kids
<0> hey mickey|thesis
<8> for space reasons, i want that .pyo-files (optimized compiled python files) are not included in the image, as we aren't using python -O. what's the easiest way to do this? some package.bbcl*** hack or is there a nicer way?
<5> morning mickey|thesis
<9> hi
<9> goxboxlive: that's no problem. those settings are specified by qpe.conf. you should really look into the OE manual one of these days to learn about OVERRIDES :D
<9> goxboxlive: I'm commiting your large icons in a second
<10> mickey i have done it allready
<10> not in the OE but just localy
<10> But i need some help with keyboard. Can we move obver to #OPIE?
<9> *sigh* still your keyboard
<9> ya
<3> mickey|thesis: i'd be interested in hearing your thoughts about my pastebin patch ;) (no pressure)
<9> zwelch: first glance looks good. does it work? :D
<3> i'm guessing that's a rhetorical question, given my comment above :D
<9> right
<3> the only improvement might be to get the name of the buffer
<3> i.e. 'buffers' shows the name of the file, and i added the description to be p***ed along... might as well use it if we can still get at it
<9> that's right.
<3> i just did what i could do locally
<3> i.e. without more knowledge of the bb code
<9> I haven't had a chance to improve the shell lately. I plan to return to it in a couple of months.
<9> + stacking a GUI on it
<3> i'll probably continue to submit patches
<9> excellent!
<11> zwelch: my glibc build died for the same reason, even after adding the most sensible PREFERRED_PROVIDERS :(
<3> Kerwood_: doh!
<3> i wish i had better advice for you :/
<11> zwelch: I need to go to other system where it worked and study the differences
<3> oooooh!
<11> I think I may have a dirty PATH
<3> wait... i just remembered what i think the problem is
<3> what version of binutils-cross are you getting?
<11> zwelch: 2.17
<3> okay, i think that might be it; you'll note i added a PREFERRED_VERSION for 2.16 in my conf
<3> sorry. i guess i steered you to the wrong PREFERRED_THINGY the first time :(
<11> zwelch: Sure enough! Wow, this might be it! Thanks -- I'll give it a whirl now.
<3> it's worth noting that 2.16 is what you want, not the 2.16.91.* versions that are also there
<12> mickeyl org.oe.dev * rc0df5bfe... /conf/distro/generic.conf: generic.conf include sane srcdates
<12> mickeyl org.oe.dev * rf8ca5d54... /conf/distro/generic-unstable.conf: generic-unstable.conf detach from generic, since we don't want to include sane-srcdates here
<12> mickeyl org.oe.dev * rfa3fb685... /packages/opie-taskbar/ (3 files in 2 dirs): opie-taskbar 1.2.2 add dedicated qpe.conf for htcuniversal
<11> zwelch: Roger dat
<6> zwelch: angstrom is using th 91.* version
<9> zwelch: patch applied in R546, thanks
<3> giel: i'm just reporting my experience... i had to rewind to 2.16 to get it working again
<6> zwelch: okay, i will note that if i get any problems
<11> zwelch: When do you plan to sleep, btw?
<3> and... i suppose that i only tried to .0.7 build
<3> Kerwood_: sleep is for the week... and the cubicle farmers
<11> zwelch: =:O
<6> zwelch: that's what angstrom is using as well, and i'm trying to build it right now
<3> Kerwood_: my patch record (as documented in the minisplat repo logs) shows my sleeping patterns can be erratic to non-existance
<11> zwelch: Well, as long as you aren't cheating with chemicals, I guess there's no harm
<6> zwelch: you can try the uberman sleep schedule
<3> wait, when did chemicals become cheating?
<11> heh
<12> zecke123 * r bitbake/lib/bb/parse/parse_c/ (BBHandler.py Makefile bitbakec.pyx): bitbake c parser: first steps torwards a working parser
<13> there we go
<12> zecke123 * r bitbake/lib/bb/parse/parse_c/ (BBHandler.py Makefile bitbakec.pyx): bitbake c parser: first steps torwards a working parser
<13> hmm, thats odd
<0> kergoth: cool
<12> zecke123 * r bitbake/lib/bb/parse/parse_c/ (BBHandler.py Makefile bitbakec.pyx): bitbake c parser: first steps torwards a working parser
<3> if i were a betting man, i would guess that is not the last we are going to hear about r544
<12> kergoth * r bitbake/a: Testing CIA notification.
<12> kergoth * r bitbake/a: Testing CIA notification, again.
<13> there, all good
<0> RP_: what's the functional status of pxa270 cpufreq?
<14> has the monotone update occured yet ?
<0> [g2]: not yet
<14> morning koen
<14> do you know when that's to occur ?
<0> yes
<0> see http://www.openembedded.org/openembedded-migration-from-monotone-0-25-to-0-27
<14> THX
<15> hello
Return to
#oe
or
Go to some related
logs:
#math
raidtools cumbersome
#centos
run application dialog fluxbox
#perl
#php
sql SELECT * apart from
gimp only on RGB color
#linux
#perl
|
|