<kristianpaul> who needs houses, land is what matters  ;-)
<kristianpaul> xiangfu: thanks for the L19_L3 mark, i just was about to find it  :)
<kristianpaul> living circumstances as a result of many events trought that culture's history too
<xiangfu> kristianpaul, :) L3 is small
<kristianpaul> even better !
<kristianpaul> (for soldering)
<wolfspraul> good morning everybody
<kristianpaul> morning
<DocScrutinizer> wpwrak: ""Was? Das Volk hat kein Brot? Soll es doch Kuchen essen"" ;-P
<wpwrak> DocScrutinizer: exactly :)
<rjeffries> some of you may find this video about Arduino (history) interesting. or not. http://postscapes.com/watch-arduino-the-documentary
<nunoiz> Hello all.
<nunoiz> Anyone around who knows about hacking Wifi antenna's ?
<vladkorotnev> Hey guys, what's up?
<nunoiz> quiet...to quiet....I got a bad feeling about this...heh..
<xiangfu> hi
<wolfspraul> vladkorotnev: hi
<wolfspraul> nunoiz was too impatient :-)
<bartbes> does that AM transmit thing actually work with the ben's lcd?
<bartbes> btw, to whoever interested in guile 2, it failed to compile on a host with guile 2 as well
<zear> hey there
<wolfspraul> hi
<zear> i haven't been updating my ben in years, but now i thought it's a good time to check what's new
<zear> although, i have a problem with installing xburst-tools
<zear> are there any precompiled packages?
<zear> i can see only packages for debian and for arch (which is 404)
<zear> i got the sources of xburst-tools, but in the INSTALL doc it says i require an owrt compiler to build it
<zear> but i remember xbusrt-tools was a set of native x86 binaries
<wolfspraul> you came just in time for the new image
<zear> :)
<kyak> oh no
<kyak> this is not the binary :)
<zear> kyak, that's the sources i already got
<kyak> grab the deb, and just unpack it
<zear> kyak, ah, of course
<zear> why didn't i think about it before
<zear> but anyway, the arch package link is dead, perhaps it's time to update/remove it from the website
<kyak> probably. Make sure you are NOT using xburst-tools older than 2011-05-30
<kyak> and i'm off :) have fun with the new image!
<zear> kyak, thanks for the help
<kristianpaul> btw freedroid segfaults after you hit poweroff when playing
<kristianpaul> then the .freedroid folder have to be deleted to make it work again
<zear> btw, does the ben still require you to hold the power button for few seconds before it boots?
<kristianpaul> not anymore
<zear> ah, great
<kristianpaul> BUT, i think the default wallpaper make gmenu2x load a bit slow
<kristianpaul> i just changed and it is really fast boot
<zear> hmm.. i'm getting tons of "./refla1/794./reflash_ben.sh: line 149: bc: no such command" messages when running reflash_ben.sh
<kristianpaul> last reflash?
<zear> the one from the wiki
<zear> i have no idea what's latest and what's not, i wasn't active in the scene since 2009 :D
<jow_laptop> zear: looks like you need to install the bash calculator (bc) on your host
<zear> jow_laptop, that doesn't sound like something everyone has by default. Why isn't it listed on the wiki in the flashing howto then?
<jow_laptop> zear: probably because the author forgot about it and/or had bc by default
<zear> i don't even seem to have it in my repository
<jow_laptop> whats your distro?
<zear> arch
<zear> oh, i do
<jow_laptop> maybe you need to activate the extra repo?
<jow_laptop> oh ok
<zear> but it's description was "An arbitrary precision calculator language"
<zear> nothing about bash
<jow_laptop> ok, sorry, maybe I got the name wrong
<zear> can i ctrl+c the reflash_ben.sh script and then run it again?
<jow_laptop> yes
<jow_laptop> I think due to the missing bc it didn't do anything useful anyway
<zear> ah
<jow_laptop> it is needed to calculate offsets and such
<zear> jow_laptop, nah, it actually trashed the nand
<zear> i'm getting a kernel panic now :D
<zear> but the bootloader seems to still be there, so i think i'll be able to software usb boot it
<zear> hmm.. is there a gcc compiler available for the nanonote?
<zear> something so i can compile natively on the ben
<zear> instead of cross-compiling
<zear> oh, there is, just found a section about it on the wiki :)
<zear> wolfspraul, i must say so far i'm impressed with the current ben firmware
<zear> it's a huge leap forward comared to the late 2009/early 2010 images
<zear> *compared
<zear> and you guys have got a port of liballegro. We'll have to adopt it to the Dingoo :)
<zear> hmm.. i'm trying to compile a program that uses only ansi c + libSDL, but i'm getting this while trying to link:
<zear> i'm building directly on the nanonote
<zear> since the toolchain required you to make a symlink to /home/xiangfu/... and i think this is unacceptable :)
<zear> *requires
<viric> bad xiangfu!
<kyak> zear: you need to install libsdl dev libs.. which you should take either from openwrt build root, or from a respective package
<zear> the repository is missing libdl, so i'm now trying to use the one from the Dingux toolchain
<zear> kyak, of course i did that long time ago
<zear> kyak, i already tried both the ones from qi-hardware website and the ones from the owrt repo
<zear> i think if i was missing libsdl, the linker would point this out on -lSDL line
<kyak> isn't libdl functionality provided by uclibc?
<zear> no idea, but then it means the sdl lib is broken
<zear> it also complains about libdirectfb which IS already installed
<jow_laptop> the above errors are not unusual
<kyak> did you provde the -rpath?
<jow_laptop> using rpath-link as suggested will solve it
<zear> kyak, no, i have no idea what that is
<zear> i've been trying to compile with LDFLAGS = -L/usr/lib/ which usually fixes such problems
<jow_laptop> rpath is bad because it affects the on-target runtime search paths while rpath-link is only compile time
<kyak> but the error message is pretty clear about what is it :)
<jow_laptop> the usual syntax is  LDFLAGS += -Wl,-rpath-link=dir/with/needed/libraries
<zear> kyak, not at all. What is the -rpath parameter of? gcc?
<jow_laptop> in openwrt usually $(STAGING_DIR)/usr/lib
<zear> gee, why openwrt must be so picky? I remember something like this was the reason i put the nanonote away back in 2009
<jow_laptop> you could also add -ldl
<jow_laptop> this will solve it as well
<zear> jow_laptop, i tried of course
<zear> to no avail ;)
<jow_laptop> its not openwrt, its the linker which fails at resolving dependant libraries of linked libraries
<jow_laptop> because during cross compilation there are not many environment places to initialize the search path from
<zear> how can the linker fail if i give him the correct location with LDFLAGS = -L/usr/lib ?
<zear> i'm not cross-compiling
<zear> i'm compiling it natively on the nanonote
<zear> and nope, the rpath-link didn't help
<jow_laptop> are you using LD or CC for linking?
<zear> gcc: unrecognized option '-rpath-link=/usr/lib/'
<zear> CC
<jow_laptop> well thats why I said the usual syntax is -Wl,-rpath-link=...
<jow_laptop> -Wl tells the CC to pass through the flag to the LD
<zear> well, CC and LD are just variables
<zear> they have no real meaning unless i define them, right?
<zear> like i do with CC = gcc
<jow_laptop> s/CC/gcc/; s/LD/ld/
<jow_laptop> gcc does not know about -rpath-link, only ld does
<jow_laptop> but gcc invokes ld
<jow_laptop> so in order to convey args only for ld you have to wrap them in -Wl,
<kyak> zear: if you didn't put Ben away back in 2009, you wouldn't have these questions by now ;)
<zear> ok, but why on earth is the nanonote's compiler so picky about everything? So far i compiled this piece of code to 8 different platforms, 2 of them not posix, and neither of them had such problems
<jow_laptop> the compiler isnt, the linker is
<zear> well, yes, the linker
<jow_laptop> and that might be due to the fact that it runs on a uclibc host system
<jow_laptop> which has differend ldso semantics than glibc
<zear> nope, i already compiled to an uclibc platform
<zear> and i had no such issues
<jow_laptop> natively?
<zear> hehe, no :D
<jow_laptop> ...
<zear> only by a cross-compiler
<jow_laptop> I wonder whether "strings $(which ld) | grep /lib" lists /usr/lib somewhere
<zear> ld: unrecognized option '-Wl,-rpath-link=/usr/lib/'
<jow_laptop> well did you call ld directly now?
<jow_laptop> or through gcc?
<zear> yes
<zear> directly
<jow_laptop> if you call it directly then omit the -Wl
<jow_laptop> if you call it through gcc then add the -Wl
<zear> ah, i see
<zear> you learn something new every day :)
<kyak> jow_laptop: http://dpaste.com/605320/
<jow_laptop> kyak: that looks broken
<kyak> ah, good :)
<jow_laptop> no wonder its behaving like it is
<jow_laptop> *does
<jow_laptop> the "=" is apparently an artefact of the way ./configure was called
<jow_laptop> or some other compile time shell / script failure
<kyak> ld is provided by binutils
<kyak> do you suspect some error there?
<jow_laptop> yes
<kyak> i don't see anything unusual..
<kyak> probably it's the defect of binutils itself
<jow_laptop> or the shell its configure was run under
<kyak> that would be bash
<jow_laptop> or /bin/sh
<zear> jow_laptop, oh great, so now it's ld: cannot find -lSDL
<kyak> do you suggest that building binutils on another host might fix the problem?
<zear> and yes, i do have libsdl in /usr/lib :)
<zear> jow_laptop, that's the full linker line: http://paste.pocoo.org/show/4z5ps8cFArnbg7h2LKs7/
<kyak> jow_laptop: i just installed binutils which i built on my host. It is even worse, the SEARCH_DIR is always prefixed with "="
<kyak> ah no, sorry, the output is the same
<jow_laptop> ld/genscripts.sh
<kyak> what a mess..
<jow_laptop> I think it boils down to "TARGET_SYSTEM_ROOT" defined during compilation
<jow_laptop> it is set to "/home/jow/devel/openwrt/trunk/build_dir/target-mips_r2_uClibc-0.9.32/binutils-2.20.1/ipkg-install" in my case and ends up in ldmain.o
<jow_laptop> all SEARCH_DIR pathes are relative to that
<jow_laptop> obviously this dir will not exist on-target
<jow_laptop> I bet calling "ld" with --sysroot=/  would result in a more sane behavior
<kyak> --with-sysroot=$(PKG_INSTALL_DIR) in Makefile seems to be the problem?
<kyak> should read --with-sysroot=/
<jow_laptop> yes
<jow_laptop> but I have no clue what the implications for building will be then
<kyak> or even drop this option..
<jow_laptop> ok ldfile.c just confirmed it, if a SEARCH_PATH entry starts with "=" it is based against the sysroot which is either supplied via cmdline or defined during compilation
<kyak> heh, you are a hardcore man :)
<kyak> this is mentioned in man ld
<kyak> "If searchdir begins with "=", then the "=" will be replaced by the sysroot prefix, a path specified when the linker is configured."
<jow_laptop> so one can either patch genscripts.sh to not emit "=" or change the configure args to not supply --sysroot or patch ldmain.c to not define TARGET_SYSTEM_ROOT
<jow_laptop> taking out --with-sysroot= is probably the best solution
<kyak> jow_laptop: http://dpaste.com/605335/
<kyak> i've taken out the --with-sysroot :)
<kyak> seems that it is working!
<viric> what are you playing with?
<kyak> with the native linker, i guess
<kyak> ok, time to sleep
<viric_> How could a swapless system hang, running processes that take a lot of memory?
<viric_> a linux, I mean.
<viric> grmbl new hang
<kristianpaul> dizy at 34 C