IRC log for #uclibc on 20100405

00:11.27*** join/#uclibc mirko (~daten@2a00:1328:e100:cccb:219:7dff:fe09:c74c)
01:20.47CIA-5503vda.linux 07master * r37f5bef63c0d 10busybox/ (7 files in 5 dirs): libbb: split update_utmp from login/getty in preparation to use it for telnetd
01:25.06*** join/#uclibc _2x2l (~andrew@c-71-233-209-245.hsd1.ma.comcast.net)
01:25.55_2x2lgreetings folks
01:27.08_2x2lso i seemed to have trashed a remote box i was on by accidentally linking my libc.so to something that doesnt exist. understandably now basically nothing ends up running but bash builtin's and already existing processes. when i try to do mv, cp, or any of the basic operations i end up seg faulting.
01:28.28_2x2lsince the ftpd was previously running i was able to log in, copy over a static version of busybee and chmod +x it, giving me some basic commands, but i can't salvage the system (i.e., restore the proper shared object) without getting root.
01:29.08_2x2li was wonder if anyone here happened to know if there was a way to use sudo with busybee (perhaps just a statically compiled version of sudo will do?)
01:31.48*** join/#uclibc dileX_ (~sd@p5B2EC126.dip.t-dialin.net)
02:04.04*** join/#uclibc calculus (~calculus@gentoo/user/calculus)
02:04.42*** join/#uclibc animeloe[net] (~animeloen@unaffiliated/animeloe)
02:37.46*** join/#uclibc Dj-Death1 (~djdeath@potipota.net)
02:56.07*** join/#uclibc Blice (~wibox@69.163.35.5)
02:56.19BliceHello. Is there any way to tell buildroot to try and make everything static?
02:56.23Blicethe libraries and binaries.
03:19.38*** join/#uclibc Dj-Death1 (~djdeath@potipota.net)
05:02.36*** join/#uclibc fabled (~fabled@letku109.adsl.netsonic.fi)
05:46.23*** join/#uclibc cokebottles (~doug@75.87.248.82)
06:03.52*** join/#uclibc ncopa (~ncopa@180.40.189.109.customer.cdi.no)
06:30.16*** join/#uclibc calculus (~calculus@gentoo/user/calculus)
08:40.49*** join/#uclibc tsukasa (~tsukasa@unaffiliated/tsukasa)
08:48.30*** join/#uclibc y_morin (~ymorin@ARennes-252-1-60-225.w83-195.abo.wanadoo.fr)
09:11.01*** join/#uclibc pentanol (~pentanol@77.35.49.164)
09:19.46*** join/#uclibc schone (~Adium@220-253-110-243.VIC.netspace.net.au)
09:20.24schonehi all im new to bb and was wondering if there is a way you can recursively set permissions of files only?
09:22.34CIA-5503paul 07master * rfaa2f0123196 10buildroot/ (CHANGES package/libdrm/Config.in package/libdrm/libdrm.mk): Bump libdrm to 2.4.19
09:22.36CIA-5503johan 07master * rcb08cd64f0fe 10buildroot/ (3 files in 2 dirs): configs/: fix uboot board name for integrator926 defconfig
09:22.36CIA-5503will_wagner 07master * rf94830d0e5a4 10buildroot/ (21 files in 10 dirs): matchbox: convert to autotools, fix build with start-notification, libxft
09:22.37CIA-5503jacmet 07master * rcd61ea772be4 10buildroot/Makefile: Makefile: out-of-tree fix for uclibc 0.9.31
09:22.38CIA-5503jacmet 07master * r266fa65afb20 10buildroot/ (4 files in 2 dirs): toolchain: add uClibc 0.9.31, mark 0.9.30.x as recent
09:25.15*** join/#uclibc tsukasa (~tsukasa@unaffiliated/tsukasa)
10:02.21mnemocschone: find -type f -print0 | xargs -r0 chmod $mod
10:04.05BlicePeople are awake! mnemoc: Good mornig.
10:04.26Blicemaybe you can answer my question. Is there any way to have buildroot build everything statically?
10:04.57mnemoci suppose there is, but i don't use buildroot
10:05.21Bliceoh
10:10.26JacmetBlice: Build options->Prefer static libraries
10:10.36JacmetBlice: but it's been a while since I last tried
10:27.38*** part/#uclibc schone (~Adium@220-253-110-243.VIC.netspace.net.au)
10:37.42BliceJacmet: Yeah I tried that, everything came out dynamic anyway :/
10:39.56JacmetBlice: everything?
10:42.36JacmetBlice: It does look like we're missing the support in busybox, will add
10:58.48BliceJacmet: Everything, yeah.
10:58.58BliceLibraries are dynamic (including libc stuff)
10:59.02Bliceand binaries
10:59.20BliceI guess now that I have the root system I could chroot in and start re-compiling everything as static...
10:59.33Blicedidn't plan on doing that much work though
11:29.52CIA-5503jacmet 07master * r3ef9b6969c8e 10buildroot/package/busybox/busybox.mk: busybox: respect BR2_PREFER_STATIC_LIB
11:50.16*** join/#uclibc bkuhn (~bkuhn@sflc/staff/conservancy.president.bkuhn)
12:49.27pentanolhello
12:52.53pentanolwhere I can found gdb for uclib and arm?
12:56.46Jacmetpentanol: buildroot can build one for you
13:00.10pentanolI've tried it http://codepad.org/7o2P5prn
13:02.58Jacmetpentanol: hmm, so this is gdb for running on the target?
13:03.16pentanolyes
13:03.33pentanolI setting it
13:03.45Jacmetpentanol: not that it matters for this, but gdbserver is normally a much better solution
13:03.56pentanolit happening with snapshor or latest 02
13:04.26pentanolI should setting there a server?
13:04.39Jacmetpentanol: strange, ncurses hasn't been updated recently
13:05.09Jacmetpentanol: gdbserver is a small (~50kb) daemon that you run on your target, which talks to a fullblown cross-gdb running on your pc
13:05.23Jacmetpentanol: I'll do a test build of ncurses
13:06.35pentanolalso I tries make gdb out of toolchain  ang got *** BFD does not support target armv5l-unknown-none
13:07.59Jacmetpentanol: so cross-gdb for the host?
13:08.17Jacmetpentanol: that works here (I normally build for powerpc though)
13:08.42pentanoljust unpack receiver archive and said here  make   ARCH=arm CPU=armv5tejl
13:09.09pentanolactually I need just debuger
13:10.32pentanolcould you try for arm?
13:11.27pentanoldid you any addition exports path's vars... ?
13:12.39Jacmetpentanol: yes, I'll give it a try once this build is done
13:13.01Jacmetpentanol: and no, I just enabled gdb support in menuconfig and built it
13:13.31pentanolin which toolchain?
13:13.48Jacmetpentanol: what do you mean?
13:13.58pentanolversion...
13:14.11pentanolhow you star compilation?
13:14.11pentanolmake   ARCH=arm CPU=armv5tejl
13:14.12Jacmetpentanol: ahh, buildroot defaults
13:14.46pentanolon my stil working
13:14.57pentanolbulding...
13:14.59Jacmetpentanol: E.G. gcc 4.3.4, binutils 2.20.1, gdb 6.8
13:15.21Jacmetpentanol: no, buildroot takes care of all those things, just make menuconfig; make
13:15.29pentanolbuildroot-2010.02 ?
13:16.18Jacmetpentanol: current git, but 2010.02 should also work
13:16.27Blice05:30 < CIA-55> jacmet master * r3ef9b6969c8e buildroot/package/busybox/busybox.mk: busybox: respect BR2_PREFER_STATIC_LIB <-- I'm not familiar with messages like this, is this a patch or a bug report?
13:17.02JacmetBlice: that's a commit notification
13:17.21BliceDoes that mean it's fixed?
13:17.21CIA-5503jacmet 07master * rc95174a8dfb6 10buildroot/toolchain/uClibc/uclibc.mk: uclibc: don't install libs to target if BR2_PREFER_STATIC_LIB
13:17.22CIA-5503jacmet 07master * r6cdcc4d7d813 10buildroot/toolchain/gcc/Config.in: gcc: hide shared libgcc option if BR2_PREFER_STATIC_LIB is enabled
13:17.40BliceAwesome.
13:17.41BliceThank you
13:17.44JacmetBlice: with that + these ones you'll atleast have the basics for static builds (uclibc + busybox)
13:17.54Blicegreat, thank you.l
13:18.57JacmetBlice: some of the other packages will still try to use --enable-shared, but this is a start atleast
13:18.58Bliceat least I won't have to recompile as many things..
13:19.13Blicecan I do "make --enable-static" on buildroot? that wouldn't be recurssive, would it?
13:19.30JacmetBlice: what packages are you interested in exactly? I would have guessed setups with static to be very small and only use busybox
13:19.44pentanolif I don't do ARCH=arm CPU=armv5tejl it looks like compiling for i386.... , but I setting in config armhttp://codepad.org/XCoY5hUe
13:19.57JacmetBlice: no, you would need to tweak the individual package/*.mk files
13:20.20BliceJacmet: http://sta.li/ - I'm making a system similar to this.
13:20.20Jacmetpentanol: what make invocation are you talking about? buildroot or building gdb by hand?
13:20.48pentanolbuildroot of course
13:21.21Jacmetpentanol: run make menuconfig to set arch
13:22.01JacmetBlice: ahh - There might very well be other issues waiting for such a "big" setup - E.G. Xorg modules
13:23.21BliceThen for such a big task I will have to learn C more so I can make difficult packages more sane!
13:23.46Blicethat or give up. We'll see.
13:24.06JacmetBlice: ;)
13:28.01pentanolweird
13:28.11pentanolon my seting arches wont work
13:28.24pentanolonlt if I said it make ARCH=arm
13:29.13Jacmetpentanol: could you put your .config somewhere?
13:30.45pentanolhttp://codepad.org/gOY4J133 there
13:31.34pentanolanyway http://codepad.org/Xp4E95U7
13:32.23pentanolshould I setting ln -s to arm-linux-uclibc-gcc ?
13:32.38Jacmetpentanol: have you done a clean rebuild (rm -rf output) after messing around with ARCH?
13:32.49pentanolyes
13:32.50Jacmetpentanol: no, you don't need to do anything manual
13:33.17pentanolbut perhaps my gc don't support this arm....
13:33.24Jacmet<PROTECTED>
13:33.55Jacmetpentanol: are you really sure you want to use oabi / generic arm support?
13:34.22pentanolyes
13:34.27pentanolmy arm use o
13:34.50pentanoland I've compilet uClib bu this way and it works on my camera
13:35.19pentanolthen I needed to compile debugger
13:35.36Jacmetpentanol: ok, just asking as that kind of setup is a bit odd in 2010
13:36.48pentanolperhapsl)
13:36.51pentanol;)
13:37.06pentanolalso I use path like /usr/local/cross-compiler-armv5l/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
13:37.35Jacmetpentanol: ohh? on the host? Don't do that
13:37.48Jacmetpentanol: don't mix your old toolchain with the new one
13:38.40pentanolwhat?
13:38.51pentanolit just path no arm compiler
13:39.25Jacmetpentanol: yes, don't do that
13:39.27pentanolor it unnecessary?
13:39.40Jacmetpentanol: you are building a new cross compiler and gdb, right?
13:39.56Jacmetpentanol: so don't do anything with your old toolchain - Don't add it to the path
13:40.15pentanolyes
13:40.43pentanolit will be compiled by modern gcc from default path...
13:42.38pentanollittle bit screwed, I heared somewhere... related  embedded compilations what it should be compiled by own brand compiler
13:43.15pentanolmay be itsn't case in uclib toolchan
13:44.55Jacmetpentanol: ..compiled by own brand .. - You mean from your board vendor?
13:45.14Jacmetpentanol: it's certainly true that you cannot mix/match uclibc versions/configurations and expect it to work
13:48.22pentanolabout brand I mean any embedded platform... and those platforms has a own compilers... perhaps they use more specific optimisations however...
13:49.13pentanolanyway buildroot-2010.02/output/build/gdbserver-6.8/.configured] Error 77
13:50.31Jacmetpentanol: in general you should compile your entire system using the same compiler / options
13:51.18pentanoli  never change it
13:51.39pentanoljust put make there as you tells me
13:56.40Jacmetpentanol: so you are now rebuilding your entire system from scratch using buildroot, while also including gdb/gdbserver?
13:57.20pentanolyes, indeed
13:57.24Jacmetpentanol: my build is not done yet, but it is past gdb so everything seems to work here
13:57.33pentanolor, could you share somewhere gdb...
13:57.39pentanolbinary for arm
13:58.00pentanolthat everything what I needed
13:58.00Jacmetpentanol: this is with defconfig, just with arch set to arm and oabi
13:59.13Jacmetpentanol: I built (cross)gdb for the host - But that depends on my host arch/libs and buildroot location, so it probably won't work for you
13:59.39pentanolbuild it static?
14:00.09Jacmetpentanol: could you try doing a clean rebuild from a clean environment? - E.G. no other cross compiler in your path, rm .config; make menuconfig, select arm+oabi+gdb for host
14:00.36*** join/#uclibc KaiForce (~chatzilla@adsl-70-228-91-140.dsl.akrnoh.ameritech.net)
14:06.20pentanolok I ran in on another pc from clear unpacked buildroot-2010.02.tar.bz2
14:06.49pentanolit*
14:09.00Jacmetpentanol: and? did it work?
14:09.58*** join/#uclibc sjhill (~sjhill@home.bethel-hill.org)
14:13.45pentanolnot so fast, it still building
14:13.54Jacmetpentanol: ok
16:20.00*** join/#uclibc trem_ (~trem@mol92-1-81-57-136-23.fbx.proxad.net)
16:25.45_2x2lso i trashed a remote box by accidentally linking libc.so to something now it doesnt exist. now basically nothing understadnably ends up running but bash builtins and already existing processes. when i try to do mv, cp or any of the basic operations i segfault.
16:26.38_2x2lsince the ftpd was previously running iw as able to log in, copy over a static version of busy by and run it. giving me basic commands but i cant salvage the system (i.e., restore the proper shared object) without getting root. is there anyway to do use sudo with busybee? i tried to statically compile sudo to no avail.
16:42.31*** join/#uclibc austinf (~austinf@74.92.231.110)
17:07.21*** join/#uclibc kos_tom (~thomas@humanoidz.org)
17:16.25y_morinbindvt: around?
17:17.17y_morinblindvt: around?
17:19.09kos_tomy_morin: hi!
17:19.09y_morinkos_tom: hello!
17:19.24y_morinkos_tom: I'm looking at bug #851
17:19.56y_morinCode for building gcc was last touched in 2007.
17:19.59kos_tomi'm reading the discussion between you and Grant, following my question.
17:20.42y_morinHe has a point: buildroot does weird things wrt --prefix and --with-sysroot.
17:21.43y_morinSo the little hack does not work.
17:23.33y_morinBasically, it boils down to toolchain/gcc/gcc-uclibc-4.x.mk at lines 278 and 283 for "./configure", and 311 for "make install".
17:24.14y_moringcc is configured with prefix=/usr, and install with DESTDIR=$(...STAGING...)
17:24.29kos_tomshouldn't we just change this ?
17:24.49kos_tomI don't know what's the meaning of --prefix for something that is supposed to be relocatable
17:24.57y_morinThat code is old, the commit message terse, and I'm looking at the implications of changing that.
17:25.46y_morinWell, neither do I. But I take 'relocatable' as beinf a hack by itself.
17:26.02y_morinAt least, you want to know where to install stuff initially, hence prefix.
17:26.20y_morinBut thne you have DESTDIR, which is expected to be used for out-of-tree installation.
17:26.25y_morinLemme get the pointers back...
17:26.47y_morinhttp://www.gnu.org/prep/standards/html_node/DESTDIR.html
17:26.54CIA-5503vda.linux 07master * r56f80b6cb623 10uClibc/libc/misc/utmp/utent.c: utent: do not create extra static functions if !THREADS
17:27.00kos_tomMy understanding for normal autotools programs is that --prefix is where the program will be run, while DESTDIR is where the program is installed.
17:27.16y_morinBasically, very usefull when preparing a staging area, for cross-compilation. Not usefull to build host tools (IMHO).
17:27.34y_morinkos_tom: correct assumption.
17:28.19Dj-Death1I have seen some toolchains using relative paths for everything
17:28.44Dj-Death1looking for where the executable stands and adding ../ to find prefix
17:29.04y_morinJust know that DESTDIR is prepended to every paths at install time, *all* of them, so this is very efficient to 'stage' an install (eg. cross-compile, or packaging for a distro).
17:29.06kos_tomy_morin: ok, but that makes the --prefix semantic really odd for relocatable things.
17:29.25y_morinkos_tom: kinda, yeah.
17:29.46kos_tomso we could just change the process that buildroot uses to build gcc so that --prefix == where the toolchain is installed by Buildroot.
17:29.53CIA-5503vda.linux 07master * rb2f0faf04264 10uClibc/libutil/ (login.c logout.c): libutil/login: was totally broken. fixed
17:30.29kos_tomanyway, imo, re-using Buildroot staging areas as toolchains is quite dangerous.
17:30.41kos_tomthe staging may well contain much more than just the toolchain
17:30.54y_morinkos_tom: that would be nice as a workaround, yes. But ultimately, what about external toolchains that do not /respect/ sysroot being below prefix?
17:30.54kos_tomit may contain an arbitrary number of installed libraries
17:31.35kos_tomy_morin: before your patch, I had thought of a different way of guessing where the sysroot is.
17:31.39y_morinusing old staging: yes, definitely, that's why a proper sysroot, untouched by packages, is really needed.
17:31.52y_morinkos_tom: yes, I'm all ears^Weyes!
17:32.02kos_tomlet me find it again :-)
17:32.24kos_tomfor the "old staging" thing, I think it's up to the user to Do The Right Thing.
17:32.57kos_tomJacmet: around?
17:33.08y_morinanyway, I won't dedicate a lot of time on #851. I'm already horibly late at.. what you know... :-(
17:34.07y_morinkos_tom: a quick and simple .config that I can test against?
17:37.52kos_tomy_morin: to reproduce #851 ?
17:38.09y_morinkos_tom: to test --prefix changes...
17:38.16kos_tomjust select ARM, unselect Busybox, unselect "tarball", and run make.
17:39.09y_morinOK. You're in command ! ;-)
17:39.18kos_tomy_morin: what about something with arm-linux-gcc -print-file-name= ?
17:40.30y_morinkos_tom: I'll check that. First: reproduce toolchain as is; second, look at -print-file-name=; third, tweak --prefix/sysroot.
17:42.06kos_tomwith -print-file-name, two problems: 1) Find a generic thing to pass to -print-file-name=???, 2) Know in a generic way how to guess the sysroot from that answer.
17:42.23y_morinlibc.so, I guess...
17:42.32Jacmetkos_tom: I am now
17:43.09y_morinOK, off I go. See ya later!
17:44.07kos_tomJacmet: great :-)
17:44.34kos_tomJacmet: which process do you want us to follow regarding the target/ cleanup work (for which I sent a status update yesterday) ?
17:44.45*** join/#uclibc Cham^ (cham@port105.ds1-abv.adsl.cybercity.dk)
17:45.38Cham^hey guys im trying to run a small 1 client shoutcast on busybox, but keep getting this error: ./sc_serv: 1: Syntax error: "(" unexpected any clues why ? =)
17:46.21nealeCham^: what does ./sc_serv look like?
17:46.39Cham^<PROTECTED>
17:46.47nealeno I mean, it's a script, what are its contents
17:46.50neale(use a pastebin)
17:46.55Jacmetkos_tom: sorry, I didn't have time to look at it yet, will do this week
17:46.56Cham^its a program shoutcast.com
17:47.02Jacmetkos_tom: any big open issues?
17:47.31Cham^so neale, if i paste it is just symbols :)
17:47.41Cham^like "Àü¹ÿÿÿÿò"
17:47.55Jacmety_morin: we btw use "real" prefix for the newer host stuff - E.G. --prefix=$REALPATH-OF-DESTDIR, nothing of the DESTDIR mess
17:48.53Jacmet_2x2l: without having root access to make busybox / sudo suid you won't get very far - Better reboot with a livecd to fix it
17:51.05nealeCham^: huh.
17:51.20nealeCham^: well, then probably it's making a call out to the shell and it expects /bin/sh to be bash.
17:51.44Cham^im not that familar with linux, only basic :P so in english? =)
17:53.18_2x2lJacmet: unfortunately its a remote server
17:53.46_2x2lJacmet: i'm a sudo'er user with no time-out or password set, i just need a way to run sudo without linking lib6.so
17:53.48nealeCham^: sc_serv is trying to run a shell script, and it wants /bin/sh to be the Bourne Again Shell from the GNU project, instead of the busybox bourne shell.
17:53.54kos_tomJacmet: no, at least not that I'm aware of.
17:54.49nealeCham^: You might see if there's a modified version of sc_serv that works with Ubuntu, which also uses a plain Bourne shell for /bin/sh instead of the Bourne Again Shell.
17:55.01kos_tomy_morin: I'm thinking whether Buildroot toolchain should get installed to a special toolchain/ directory in a more toolchain-istic way, and then we could use the same process as the one we use for external toolchains.
17:55.06nealebut probably they just modified it to run /bin/bash instead of /bin/sh so meh
17:55.14kos_tomy_morin: this would also allow to avoid having host tools in the staging directory.
17:55.26Jacmet_2x2l: yes, but sudo has to be suid root, which you cannot do before your're root, so you're stuck
17:56.25_2x2lCham^: i had that issue, you need to install ia32-libs to get it to work.
17:56.31_2x2lJacmet: damnit. that's what i feared.
17:56.47Jacmetkos_tom: as long as we don't break the current setups - E.G. people can add $staging/usr/bin to the path and do $cross-gcc -o blah blah.c without passing any -I, -L or --sysroot flags
17:57.11_2x2lJacmet: alright thanks for the confirmation i suppose (despite it being relatively damning haha) time to put in a KVM request.
17:57.16Jacmet_2x2l: breaking stuff is often the best way of learning how things work :P
17:57.16Cham^_2x2l arr i see, where to install and where do i get it :D
17:57.24kos_tomJacmet: hum, this would of course be broken by what I was proposing, so not a good idea.
17:57.31neale_2x2l: how bizarre.  What in ia32-libs makes a "(" character OK?
17:57.33Jacmetkos_tom: I'm afraid not
17:57.59_2x2lneale: i have NO idea, but that's what fixed it when i had that issue, and thats what the shoutcast forms told me to do.
17:58.03_2x2lfeel free to investigate though.
17:58.16nealeI feel like I've just entered bizarro land.
17:58.24_2x2lJacmet: breaking someone elses box makes you feel like an incompetent fool though.
17:58.27_2x2ls/forms/forums/
17:58.38Jacmet_2x2l: ;)
17:58.54_2x2l:x
18:01.49Cham^neale, i had shoutcast working on a ubuntu machine
18:02.04kos_tomJacmet: BTW, I think we need to change the way $(BUILD_DIR)/%/.stamp_downloaded is implemented in the package infrastructure.
18:02.09nealeCham^: well, do what _2x2l suggests, obviously my blind guess was way off.
18:02.33Cham^heh, well just need to know where to get it, where to install it and how :D
18:02.40kos_tomJacmet: the current way doesn't remove partially downloaded tarballs when the download is interrupted.
18:02.43_2x2lCham^: sudo apt-get install ia32-libs
18:02.59Cham^that do not work in busybox :\
18:03.15_2x2loh, HUH, i forgot what channel i was in, hold.
18:03.28Cham^;)
18:03.33kos_tomJacmet: another question. I have currently one clone of the Buildroot tree, with my set of branches. But when I'm doing a test build of this tree, I cannot work on something else.
18:03.52kos_tomJacmet: do you have several full clones of the Buildroot tree ? If so, how do exchange branches between those trees ?
18:04.10nealeCham^: what is this on, openwrt?
18:04.18Jacmetkos_tom: no, that's a long standing issue - We have the same issue if you do builds in parallel with the same download dir (like we typically do with buildbot)
18:04.31Cham^neale synology NAS
18:05.14Jacmetkos_tom: no, I normally only have 1 tree - I only have a slow laptop anyway, so trying to do multiple builds in parallel isn't really an option
18:05.38Jacmetkos_tom: but that should afaik get fixed bu the proposed extensions to the out-of-tree builds
18:05.42kos_tomJacmet: it's not really doing multiple builds in my case, but rather building something *and* working on something else at the same time.
18:05.48nealeCham^: does it have ipkg perhaps?
18:05.50Jacmetkos_tom: E.G. where .config is located in O=<dir>
18:06.10Cham^maybe? =)
18:06.21Cham^Cham-Server> ipkg
18:06.21Cham^-ash: ipkg: not found
18:06.41nealeCham^: I don't know that anybody in this channel is going to be able to help you get ia32-libs on that box.  Is there a synology mail list or anything?
18:06.53Cham^a forum thingy =)
18:07.04nealeYou may have better luck there.
18:07.33nealeI'm not convinced that's the answer though, that looks like it probably has an atom CPU.
18:07.39nealewhich is already ia32
18:07.55nealeor maybe, depending on what model you have, an ARM, which isn't IA at all.
18:09.22Cham^hehe ye ok tnx neale
18:10.00_2x2lCham^: i might be horribly mistaken, the context in which i encountered that error was a 64bit server ubuntu server box. it just happened to be the same error being thrown.
18:10.32_2x2luntil you get independent confirmation, i wouldn't invest _too_ much time pursuing that lead
18:11.36nealesure looks like a bashism to me
18:12.37_2x2lneale: it did to me as well, but for whatever reason installing that package immediately solved the problem, and i was too euphoric to figure out why heh
18:12.50nealesure :)
18:17.56Cham^tnx anyways guys =)
18:24.46Jacmethacks avr today ..
18:42.22y_morinJacmet: wrt DESTDIR: I thonk this is an error to use prefix=destdir. The prefix is sometimes hard-coded in binaries so they find their data files.
18:43.14y_morinkos_tom: using a dedicated toolchain/ structure would be nice, yes. It would avoid all the nasty things we are currently doing wrt sysroot and the likes...
18:48.31y_morinJacmet: never mind, I misread host for target in your message. Yes, using prefix=DESTDIR is good for _host_ tools.
18:49.17Jacmety_morin: exactly - for target it doesn't make sense
18:49.29y_morinJacmet: yes, sure. :-)
18:49.32*** join/#uclibc mirko (~daten@g225064212.adsl.alicedsl.de)
19:08.00*** join/#uclibc dougmencken (~Douglas@93.123.156.139)
19:09.39kos_tomy_morin: I have a config file for Buildroot to make it generate an ARM toolchain.
19:09.52y_morinkos_tom: yes, please!
19:10.07y_morinI tried a few runs, and all bail out when building gcc...
19:10.29kos_tomhttp://code.bulix.org/6uzjon-74666?raw
19:12.39y_morinOK, will try. Thx.
19:14.01kos_tomI also have patches pending to support multilib toolchains such as CodeSourcery toolchains.
19:15.28y_morinkos_tom: hey! :-)
19:19.04*** join/#uclibc mnt_real (~sinan@bas1-montreal43-2925257742.dsl.bell.ca)
19:41.05kos_tomy_morin: there are sometimes some odd messages with ct-ng, like http://code.bulix.org/ru0dr6-74669?raw
19:41.17kos_tomy_morin: it says to look in a log file for details, but the name of the log file is empty.
19:41.30kos_tomthis usually appears when the failure takes place at the very beginning of the build proces
19:41.56y_morinkos_tom: OK, I know of that one.
19:42.47y_morinLog filel is not yet created. To create the log file, we need the install directory, but it requires knowing the proper tuple.
19:42.55y_morins/filel/file/
19:43.16Jacmety_morin: you have problems building a toolchain with buildroot?
19:43.36y_morinJacmet: now OK, with kos_tom's .config.
19:43.56y_morinI just tried some default to do a quick build to see if I could tackle bug #851.
19:44.06Jacmety_morin: and a normal rm .config; make menuconfig; select arch; save; make doesn't work for you?
19:44.29y_morinJacmet: nope. Bails out when build initial (stage 1) gcc.
19:44.37y_morinSmthg to do with CTOR/DTOR...
19:45.01Jacmety_morin: strange - Just normal arm eabi?
19:45.17Jacmety_morin: I built that 2-3 times today without problems
19:45.35Jacmety_morin: both with uclibc 0.9.30.x and 0.9.31 and gcc 4.3.x / 4.4.x
19:46.38y_morinFresh clone -> make menuconfig -> select ARM, uClibc-0.9.30.x -> save -> make
19:46.42y_morinI'll check again.
19:47.54kos_tomy_morin: by any change, do you have an already existing ARM toolchain in your PATH ?
19:48.00kos_toms/change/chance/
19:48.29y_morinkos_tom: Gosh. You're right. Sigh...
19:48.52Jacmetwee, my debouncing / pulse counter thingy works
19:50.19y_morinJacmet: tic tic tic... ;-)
19:51.49kos_tomy_morin: it might be interfering with the build process.
19:52.04y_morinkos_tom: I just wiped it out...
19:52.14Jacmety_morin: it's for my solar panels, so I can rrdtool'e the output
19:52.14y_morinand restarted from scratch
19:52.32y_morinJacmet: going green?
19:52.44Jacmety_morin: yeah, kind of
19:53.23Jacmety_morin: our house is ~2 years old, and we tried to do as much "green" as we could (within budget)
19:55.24y_morinHow on earth do I tell git that I want to copy file foo/bar to foo/buz ?
19:55.57y_morinSo I can use foo/bar as a base for foo/buz .
19:56.09Jacmety_morin: you don't git figures that out itself
19:56.50y_morinJacmet: so, plain cp, followed by git add and git commit.
19:57.19Jacmety_morin: yes
19:59.22Jacmety_morin: git show -C should normally show that it was a copy after commit
20:00.19Jacmety_morin: E.G. cp foo baz; git add baz; git diff -C HEAD
20:00.33Jacmetdiff --git a/Makefile b/Makefile2
20:00.33Jacmetsimilarity index 100%
20:00.33Jacmetcopy from Makefile
20:00.34Jacmetcopy to Makefile2
20:01.59y_morinJacmet: OK Thx!
20:02.23y_morinkos_tom: Yeah! T'was the other arm toolchain that caused the issue.
20:02.56Jacmety_morin: we should probably detect that and warn/error out
20:04.15y_morinJacmet: but what then? Do we require the user to remove all toolchains? Maybe he/she has no write access, and the PATH is required for something else... :-(
20:05.32Jacmety_morin: well, the best would certainly be to not screw up and get affected by the other toolchain - But if we cannot do that, then atleast error out right away as the build WILL fail anyway
20:06.58y_morinJacmet: yes, it's better to detect and error out right away, avoids a useless coffee-break! :-]
20:07.20Jacmety_morin: ;)
20:11.57CIA-5503vda.linux 07master * r3a41611bc5dd 10busybox/ (7 files in 6 dirs): telnetd: write LOGIN/DEAD_PROCESS utmp records. Closes bug 1363
20:21.06*** join/#uclibc gnomon (~gnomon@CPE0022158a8221-CM000f9f776f96.cpe.net.cable.rogers.com)
20:32.29pentanolJacmet there? anyway it's brocken buildroot-2010.02/output/build/gdbserver-6.8/.configured] Error 77
20:33.01Jacmetpentanol: strange - it built fine here
20:34.27pentanolwhich linux your pc runs?
20:35.36Jacmetpentanol: debian (64bit)
20:36.27pentanolhm, I'm on debian i386
20:38.26Jacmetpentanol: shouldn't matter
20:40.09*** join/#uclibc dileX (~sd@p5B2EC126.dip.t-dialin.net)
20:52.19pentanolit said that because while configure script it changes C compiler... checking for C compiler default output file name... configure: error: C compiler cannot create executables
20:52.32pentanol--target=arm-linux-uclibc
20:52.45pentanolmeans rm-linux-uclibc-gcc
20:52.48pentanolarm*
20:52.59Jacmetpentanol: and you're sure you no longer have another cross compiler in your path?
20:53.29pentanolno
20:53.32pentanolI've not
20:55.32Jacmetpentanol: sorry, have no idea why it then fails for you
20:57.38pentanolcould you give me output when it start ./configure gdb on your machine?
20:57.47pentanoland flags....
21:01.00Jacmetpentanol: I don't have the build anymore, but the invocation should be exactly as yours
21:01.11Jacmetpentanol: does you config.log show anything of interest?
21:02.48pentanolactually trouble with this flags... --build=i386-pc-linux-gnu                 --host=armv5l                 --target=arm
21:02.54pentanolwhich on yours?
21:03.34pentanolalso it changes arch gsb building
21:03.37pentanolgdb8
21:06.57Jacmetpentanol: hmm, that --host should come from REAL_GNU_TARGET_NAME - E.G. arm-linux-uclibc
21:45.40*** join/#uclibc gnomon (~gnomon@CPE0022158a8221-CM000f9f776f96.cpe.net.cable.rogers.com)
21:46.05CIA-5503rep.dot.nop 07master * r1d0e75b7c05f 10uClibc-website/ (news.html oldnews.html): announce 0.9.31
22:04.38CIA-5503vda.linux 07master * r37bc1eb5cdca 10busybox/include/usage.h: removed extra \n in fdisk help text
22:54.37*** join/#uclibc dieter|work (~dieter@dslb-088-066-206-011.pools.arcor-ip.net)
23:18.19*** join/#uclibc bkuhn (~bkuhn@sflc/staff/conservancy.president.bkuhn)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.