00:11.27 | *** join/#uclibc mirko (~daten@2a00:1328:e100:cccb:219:7dff:fe09:c74c) |
01:20.47 | CIA-55 | 03vda.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 | _2x2l | greetings folks |
01:27.08 | _2x2l | so 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 | _2x2l | since 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 | _2x2l | i 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.19 | Blice | Hello. Is there any way to tell buildroot to try and make everything static? |
02:56.23 | Blice | the 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.24 | schone | hi all im new to bb and was wondering if there is a way you can recursively set permissions of files only? |
09:22.34 | CIA-55 | 03paul 07master * rfaa2f0123196 10buildroot/ (CHANGES package/libdrm/Config.in package/libdrm/libdrm.mk): Bump libdrm to 2.4.19 |
09:22.36 | CIA-55 | 03johan 07master * rcb08cd64f0fe 10buildroot/ (3 files in 2 dirs): configs/: fix uboot board name for integrator926 defconfig |
09:22.36 | CIA-55 | 03will_wagner 07master * rf94830d0e5a4 10buildroot/ (21 files in 10 dirs): matchbox: convert to autotools, fix build with start-notification, libxft |
09:22.37 | CIA-55 | 03jacmet 07master * rcd61ea772be4 10buildroot/Makefile: Makefile: out-of-tree fix for uclibc 0.9.31 |
09:22.38 | CIA-55 | 03jacmet 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.21 | mnemoc | schone: find -type f -print0 | xargs -r0 chmod $mod |
10:04.05 | Blice | People are awake! mnemoc: Good mornig. |
10:04.26 | Blice | maybe you can answer my question. Is there any way to have buildroot build everything statically? |
10:04.57 | mnemoc | i suppose there is, but i don't use buildroot |
10:05.21 | Blice | oh |
10:10.26 | Jacmet | Blice: Build options->Prefer static libraries |
10:10.36 | Jacmet | Blice: 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.42 | Blice | Jacmet: Yeah I tried that, everything came out dynamic anyway :/ |
10:39.56 | Jacmet | Blice: everything? |
10:42.36 | Jacmet | Blice: It does look like we're missing the support in busybox, will add |
10:58.48 | Blice | Jacmet: Everything, yeah. |
10:58.58 | Blice | Libraries are dynamic (including libc stuff) |
10:59.02 | Blice | and binaries |
10:59.20 | Blice | I guess now that I have the root system I could chroot in and start re-compiling everything as static... |
10:59.33 | Blice | didn't plan on doing that much work though |
11:29.52 | CIA-55 | 03jacmet 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.27 | pentanol | hello |
12:52.53 | pentanol | where I can found gdb for uclib and arm? |
12:56.46 | Jacmet | pentanol: buildroot can build one for you |
13:00.10 | pentanol | I've tried it http://codepad.org/7o2P5prn |
13:02.58 | Jacmet | pentanol: hmm, so this is gdb for running on the target? |
13:03.16 | pentanol | yes |
13:03.33 | pentanol | I setting it |
13:03.45 | Jacmet | pentanol: not that it matters for this, but gdbserver is normally a much better solution |
13:03.56 | pentanol | it happening with snapshor or latest 02 |
13:04.26 | pentanol | I should setting there a server? |
13:04.39 | Jacmet | pentanol: strange, ncurses hasn't been updated recently |
13:05.09 | Jacmet | pentanol: 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.23 | Jacmet | pentanol: I'll do a test build of ncurses |
13:06.35 | pentanol | also I tries make gdb out of toolchain ang got *** BFD does not support target armv5l-unknown-none |
13:07.59 | Jacmet | pentanol: so cross-gdb for the host? |
13:08.17 | Jacmet | pentanol: that works here (I normally build for powerpc though) |
13:08.42 | pentanol | just unpack receiver archive and said here make ARCH=arm CPU=armv5tejl |
13:09.09 | pentanol | actually I need just debuger |
13:10.32 | pentanol | could you try for arm? |
13:11.27 | pentanol | did you any addition exports path's vars... ? |
13:12.39 | Jacmet | pentanol: yes, I'll give it a try once this build is done |
13:13.01 | Jacmet | pentanol: and no, I just enabled gdb support in menuconfig and built it |
13:13.31 | pentanol | in which toolchain? |
13:13.48 | Jacmet | pentanol: what do you mean? |
13:13.58 | pentanol | version... |
13:14.11 | pentanol | how you star compilation? |
13:14.11 | pentanol | make ARCH=arm CPU=armv5tejl |
13:14.12 | Jacmet | pentanol: ahh, buildroot defaults |
13:14.46 | pentanol | on my stil working |
13:14.57 | pentanol | bulding... |
13:14.59 | Jacmet | pentanol: E.G. gcc 4.3.4, binutils 2.20.1, gdb 6.8 |
13:15.21 | Jacmet | pentanol: no, buildroot takes care of all those things, just make menuconfig; make |
13:15.29 | pentanol | buildroot-2010.02 ? |
13:16.18 | Jacmet | pentanol: current git, but 2010.02 should also work |
13:16.27 | Blice | 05: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.02 | Jacmet | Blice: that's a commit notification |
13:17.21 | Blice | Does that mean it's fixed? |
13:17.21 | CIA-55 | 03jacmet 07master * rc95174a8dfb6 10buildroot/toolchain/uClibc/uclibc.mk: uclibc: don't install libs to target if BR2_PREFER_STATIC_LIB |
13:17.22 | CIA-55 | 03jacmet 07master * r6cdcc4d7d813 10buildroot/toolchain/gcc/Config.in: gcc: hide shared libgcc option if BR2_PREFER_STATIC_LIB is enabled |
13:17.40 | Blice | Awesome. |
13:17.41 | Blice | Thank you |
13:17.44 | Jacmet | Blice: with that + these ones you'll atleast have the basics for static builds (uclibc + busybox) |
13:17.54 | Blice | great, thank you.l |
13:18.57 | Jacmet | Blice: some of the other packages will still try to use --enable-shared, but this is a start atleast |
13:18.58 | Blice | at least I won't have to recompile as many things.. |
13:19.13 | Blice | can I do "make --enable-static" on buildroot? that wouldn't be recurssive, would it? |
13:19.30 | Jacmet | Blice: what packages are you interested in exactly? I would have guessed setups with static to be very small and only use busybox |
13:19.44 | pentanol | if 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.57 | Jacmet | Blice: no, you would need to tweak the individual package/*.mk files |
13:20.20 | Blice | Jacmet: http://sta.li/ - I'm making a system similar to this. |
13:20.20 | Jacmet | pentanol: what make invocation are you talking about? buildroot or building gdb by hand? |
13:20.48 | pentanol | buildroot of course |
13:21.21 | Jacmet | pentanol: run make menuconfig to set arch |
13:22.01 | Jacmet | Blice: ahh - There might very well be other issues waiting for such a "big" setup - E.G. Xorg modules |
13:23.21 | Blice | Then for such a big task I will have to learn C more so I can make difficult packages more sane! |
13:23.46 | Blice | that or give up. We'll see. |
13:24.06 | Jacmet | Blice: ;) |
13:28.01 | pentanol | weird |
13:28.11 | pentanol | on my seting arches wont work |
13:28.24 | pentanol | onlt if I said it make ARCH=arm |
13:29.13 | Jacmet | pentanol: could you put your .config somewhere? |
13:30.45 | pentanol | http://codepad.org/gOY4J133 there |
13:31.34 | pentanol | anyway http://codepad.org/Xp4E95U7 |
13:32.23 | pentanol | should I setting ln -s to arm-linux-uclibc-gcc ? |
13:32.38 | Jacmet | pentanol: have you done a clean rebuild (rm -rf output) after messing around with ARCH? |
13:32.49 | pentanol | yes |
13:32.50 | Jacmet | pentanol: no, you don't need to do anything manual |
13:33.17 | pentanol | but perhaps my gc don't support this arm.... |
13:33.24 | Jacmet | <PROTECTED> |
13:33.55 | Jacmet | pentanol: are you really sure you want to use oabi / generic arm support? |
13:34.22 | pentanol | yes |
13:34.27 | pentanol | my arm use o |
13:34.50 | pentanol | and I've compilet uClib bu this way and it works on my camera |
13:35.19 | pentanol | then I needed to compile debugger |
13:35.36 | Jacmet | pentanol: ok, just asking as that kind of setup is a bit odd in 2010 |
13:36.48 | pentanol | perhapsl) |
13:36.51 | pentanol | ;) |
13:37.06 | pentanol | also I use path like /usr/local/cross-compiler-armv5l/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin |
13:37.35 | Jacmet | pentanol: ohh? on the host? Don't do that |
13:37.48 | Jacmet | pentanol: don't mix your old toolchain with the new one |
13:38.40 | pentanol | what? |
13:38.51 | pentanol | it just path no arm compiler |
13:39.25 | Jacmet | pentanol: yes, don't do that |
13:39.27 | pentanol | or it unnecessary? |
13:39.40 | Jacmet | pentanol: you are building a new cross compiler and gdb, right? |
13:39.56 | Jacmet | pentanol: so don't do anything with your old toolchain - Don't add it to the path |
13:40.15 | pentanol | yes |
13:40.43 | pentanol | it will be compiled by modern gcc from default path... |
13:42.38 | pentanol | little bit screwed, I heared somewhere... related embedded compilations what it should be compiled by own brand compiler |
13:43.15 | pentanol | may be itsn't case in uclib toolchan |
13:44.55 | Jacmet | pentanol: ..compiled by own brand .. - You mean from your board vendor? |
13:45.14 | Jacmet | pentanol: it's certainly true that you cannot mix/match uclibc versions/configurations and expect it to work |
13:48.22 | pentanol | about brand I mean any embedded platform... and those platforms has a own compilers... perhaps they use more specific optimisations however... |
13:49.13 | pentanol | anyway buildroot-2010.02/output/build/gdbserver-6.8/.configured] Error 77 |
13:50.31 | Jacmet | pentanol: in general you should compile your entire system using the same compiler / options |
13:51.18 | pentanol | i never change it |
13:51.39 | pentanol | just put make there as you tells me |
13:56.40 | Jacmet | pentanol: so you are now rebuilding your entire system from scratch using buildroot, while also including gdb/gdbserver? |
13:57.20 | pentanol | yes, indeed |
13:57.24 | Jacmet | pentanol: my build is not done yet, but it is past gdb so everything seems to work here |
13:57.33 | pentanol | or, could you share somewhere gdb... |
13:57.39 | pentanol | binary for arm |
13:58.00 | pentanol | that everything what I needed |
13:58.00 | Jacmet | pentanol: this is with defconfig, just with arch set to arm and oabi |
13:59.13 | Jacmet | pentanol: 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.39 | pentanol | build it static? |
14:00.09 | Jacmet | pentanol: 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.20 | pentanol | ok I ran in on another pc from clear unpacked buildroot-2010.02.tar.bz2 |
14:06.49 | pentanol | it* |
14:09.00 | Jacmet | pentanol: and? did it work? |
14:09.58 | *** join/#uclibc sjhill (~sjhill@home.bethel-hill.org) |
14:13.45 | pentanol | not so fast, it still building |
14:13.54 | Jacmet | pentanol: ok |
16:20.00 | *** join/#uclibc trem_ (~trem@mol92-1-81-57-136-23.fbx.proxad.net) |
16:25.45 | _2x2l | so 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 | _2x2l | since 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.25 | y_morin | bindvt: around? |
17:17.17 | y_morin | blindvt: around? |
17:19.09 | kos_tom | y_morin: hi! |
17:19.09 | y_morin | kos_tom: hello! |
17:19.24 | y_morin | kos_tom: I'm looking at bug #851 |
17:19.56 | y_morin | Code for building gcc was last touched in 2007. |
17:19.59 | kos_tom | i'm reading the discussion between you and Grant, following my question. |
17:20.42 | y_morin | He has a point: buildroot does weird things wrt --prefix and --with-sysroot. |
17:21.43 | y_morin | So the little hack does not work. |
17:23.33 | y_morin | Basically, 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.14 | y_morin | gcc is configured with prefix=/usr, and install with DESTDIR=$(...STAGING...) |
17:24.29 | kos_tom | shouldn't we just change this ? |
17:24.49 | kos_tom | I don't know what's the meaning of --prefix for something that is supposed to be relocatable |
17:24.57 | y_morin | That code is old, the commit message terse, and I'm looking at the implications of changing that. |
17:25.46 | y_morin | Well, neither do I. But I take 'relocatable' as beinf a hack by itself. |
17:26.02 | y_morin | At least, you want to know where to install stuff initially, hence prefix. |
17:26.20 | y_morin | But thne you have DESTDIR, which is expected to be used for out-of-tree installation. |
17:26.25 | y_morin | Lemme get the pointers back... |
17:26.47 | y_morin | http://www.gnu.org/prep/standards/html_node/DESTDIR.html |
17:26.54 | CIA-55 | 03vda.linux 07master * r56f80b6cb623 10uClibc/libc/misc/utmp/utent.c: utent: do not create extra static functions if !THREADS |
17:27.00 | kos_tom | My 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.16 | y_morin | Basically, very usefull when preparing a staging area, for cross-compilation. Not usefull to build host tools (IMHO). |
17:27.34 | y_morin | kos_tom: correct assumption. |
17:28.19 | Dj-Death1 | I have seen some toolchains using relative paths for everything |
17:28.44 | Dj-Death1 | looking for where the executable stands and adding ../ to find prefix |
17:29.04 | y_morin | Just 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.06 | kos_tom | y_morin: ok, but that makes the --prefix semantic really odd for relocatable things. |
17:29.25 | y_morin | kos_tom: kinda, yeah. |
17:29.46 | kos_tom | so we could just change the process that buildroot uses to build gcc so that --prefix == where the toolchain is installed by Buildroot. |
17:29.53 | CIA-55 | 03vda.linux 07master * rb2f0faf04264 10uClibc/libutil/ (login.c logout.c): libutil/login: was totally broken. fixed |
17:30.29 | kos_tom | anyway, imo, re-using Buildroot staging areas as toolchains is quite dangerous. |
17:30.41 | kos_tom | the staging may well contain much more than just the toolchain |
17:30.54 | y_morin | kos_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.54 | kos_tom | it may contain an arbitrary number of installed libraries |
17:31.35 | kos_tom | y_morin: before your patch, I had thought of a different way of guessing where the sysroot is. |
17:31.39 | y_morin | using old staging: yes, definitely, that's why a proper sysroot, untouched by packages, is really needed. |
17:31.52 | y_morin | kos_tom: yes, I'm all ears^Weyes! |
17:32.02 | kos_tom | let me find it again :-) |
17:32.24 | kos_tom | for the "old staging" thing, I think it's up to the user to Do The Right Thing. |
17:32.57 | kos_tom | Jacmet: around? |
17:33.08 | y_morin | anyway, I won't dedicate a lot of time on #851. I'm already horibly late at.. what you know... :-( |
17:34.07 | y_morin | kos_tom: a quick and simple .config that I can test against? |
17:37.52 | kos_tom | y_morin: to reproduce #851 ? |
17:38.09 | y_morin | kos_tom: to test --prefix changes... |
17:38.16 | kos_tom | just select ARM, unselect Busybox, unselect "tarball", and run make. |
17:39.09 | y_morin | OK. You're in command ! ;-) |
17:39.18 | kos_tom | y_morin: what about something with arm-linux-gcc -print-file-name= ? |
17:40.30 | y_morin | kos_tom: I'll check that. First: reproduce toolchain as is; second, look at -print-file-name=; third, tweak --prefix/sysroot. |
17:42.06 | kos_tom | with -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.23 | y_morin | libc.so, I guess... |
17:42.32 | Jacmet | kos_tom: I am now |
17:43.09 | y_morin | OK, off I go. See ya later! |
17:44.07 | kos_tom | Jacmet: great :-) |
17:44.34 | kos_tom | Jacmet: 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.38 | Cham^ | 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.21 | neale | Cham^: what does ./sc_serv look like? |
17:46.39 | Cham^ | <PROTECTED> |
17:46.47 | neale | no I mean, it's a script, what are its contents |
17:46.50 | neale | (use a pastebin) |
17:46.55 | Jacmet | kos_tom: sorry, I didn't have time to look at it yet, will do this week |
17:46.56 | Cham^ | its a program shoutcast.com |
17:47.02 | Jacmet | kos_tom: any big open issues? |
17:47.31 | Cham^ | so neale, if i paste it is just symbols :) |
17:47.41 | Cham^ | like "Àü¹ÿÿÿÿò" |
17:47.55 | Jacmet | y_morin: we btw use "real" prefix for the newer host stuff - E.G. --prefix=$REALPATH-OF-DESTDIR, nothing of the DESTDIR mess |
17:48.53 | Jacmet | _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.05 | neale | Cham^: huh. |
17:51.20 | neale | Cham^: well, then probably it's making a call out to the shell and it expects /bin/sh to be bash. |
17:51.44 | Cham^ | im not that familar with linux, only basic :P so in english? =) |
17:53.18 | _2x2l | Jacmet: unfortunately its a remote server |
17:53.46 | _2x2l | Jacmet: 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.48 | neale | Cham^: 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.54 | kos_tom | Jacmet: no, at least not that I'm aware of. |
17:54.49 | neale | Cham^: 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.01 | kos_tom | y_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.06 | neale | but probably they just modified it to run /bin/bash instead of /bin/sh so meh |
17:55.14 | kos_tom | y_morin: this would also allow to avoid having host tools in the staging directory. |
17:55.26 | Jacmet | _2x2l: yes, but sudo has to be suid root, which you cannot do before your're root, so you're stuck |
17:56.25 | _2x2l | Cham^: i had that issue, you need to install ia32-libs to get it to work. |
17:56.31 | _2x2l | Jacmet: damnit. that's what i feared. |
17:56.47 | Jacmet | kos_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 | _2x2l | Jacmet: alright thanks for the confirmation i suppose (despite it being relatively damning haha) time to put in a KVM request. |
17:57.16 | Jacmet | _2x2l: breaking stuff is often the best way of learning how things work :P |
17:57.16 | Cham^ | _2x2l arr i see, where to install and where do i get it :D |
17:57.24 | kos_tom | Jacmet: hum, this would of course be broken by what I was proposing, so not a good idea. |
17:57.31 | neale | _2x2l: how bizarre. What in ia32-libs makes a "(" character OK? |
17:57.33 | Jacmet | kos_tom: I'm afraid not |
17:57.59 | _2x2l | neale: 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 | _2x2l | feel free to investigate though. |
17:58.16 | neale | I feel like I've just entered bizarro land. |
17:58.24 | _2x2l | Jacmet: breaking someone elses box makes you feel like an incompetent fool though. |
17:58.27 | _2x2l | s/forms/forums/ |
17:58.38 | Jacmet | _2x2l: ;) |
17:58.54 | _2x2l | :x |
18:01.49 | Cham^ | neale, i had shoutcast working on a ubuntu machine |
18:02.04 | kos_tom | Jacmet: BTW, I think we need to change the way $(BUILD_DIR)/%/.stamp_downloaded is implemented in the package infrastructure. |
18:02.09 | neale | Cham^: well, do what _2x2l suggests, obviously my blind guess was way off. |
18:02.33 | Cham^ | heh, well just need to know where to get it, where to install it and how :D |
18:02.40 | kos_tom | Jacmet: the current way doesn't remove partially downloaded tarballs when the download is interrupted. |
18:02.43 | _2x2l | Cham^: sudo apt-get install ia32-libs |
18:02.59 | Cham^ | that do not work in busybox :\ |
18:03.15 | _2x2l | oh, HUH, i forgot what channel i was in, hold. |
18:03.28 | Cham^ | ;) |
18:03.33 | kos_tom | Jacmet: 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.52 | kos_tom | Jacmet: do you have several full clones of the Buildroot tree ? If so, how do exchange branches between those trees ? |
18:04.10 | neale | Cham^: what is this on, openwrt? |
18:04.18 | Jacmet | kos_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.31 | Cham^ | neale synology NAS |
18:05.14 | Jacmet | kos_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.38 | Jacmet | kos_tom: but that should afaik get fixed bu the proposed extensions to the out-of-tree builds |
18:05.42 | kos_tom | Jacmet: 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.48 | neale | Cham^: does it have ipkg perhaps? |
18:05.50 | Jacmet | kos_tom: E.G. where .config is located in O=<dir> |
18:06.10 | Cham^ | maybe? =) |
18:06.21 | Cham^ | Cham-Server> ipkg |
18:06.21 | Cham^ | -ash: ipkg: not found |
18:06.41 | neale | Cham^: 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.53 | Cham^ | a forum thingy =) |
18:07.04 | neale | You may have better luck there. |
18:07.33 | neale | I'm not convinced that's the answer though, that looks like it probably has an atom CPU. |
18:07.39 | neale | which is already ia32 |
18:07.55 | neale | or maybe, depending on what model you have, an ARM, which isn't IA at all. |
18:09.22 | Cham^ | hehe ye ok tnx neale |
18:10.00 | _2x2l | Cham^: 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 | _2x2l | until you get independent confirmation, i wouldn't invest _too_ much time pursuing that lead |
18:11.36 | neale | sure looks like a bashism to me |
18:12.37 | _2x2l | neale: 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.50 | neale | sure :) |
18:17.56 | Cham^ | tnx anyways guys =) |
18:24.46 | Jacmet | hacks avr today .. |
18:42.22 | y_morin | Jacmet: 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.14 | y_morin | kos_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.31 | y_morin | Jacmet: never mind, I misread host for target in your message. Yes, using prefix=DESTDIR is good for _host_ tools. |
18:49.17 | Jacmet | y_morin: exactly - for target it doesn't make sense |
18:49.29 | y_morin | Jacmet: 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.39 | kos_tom | y_morin: I have a config file for Buildroot to make it generate an ARM toolchain. |
19:09.52 | y_morin | kos_tom: yes, please! |
19:10.07 | y_morin | I tried a few runs, and all bail out when building gcc... |
19:10.29 | kos_tom | http://code.bulix.org/6uzjon-74666?raw |
19:12.39 | y_morin | OK, will try. Thx. |
19:14.01 | kos_tom | I also have patches pending to support multilib toolchains such as CodeSourcery toolchains. |
19:15.28 | y_morin | kos_tom: hey! :-) |
19:19.04 | *** join/#uclibc mnt_real (~sinan@bas1-montreal43-2925257742.dsl.bell.ca) |
19:41.05 | kos_tom | y_morin: there are sometimes some odd messages with ct-ng, like http://code.bulix.org/ru0dr6-74669?raw |
19:41.17 | kos_tom | y_morin: it says to look in a log file for details, but the name of the log file is empty. |
19:41.30 | kos_tom | this usually appears when the failure takes place at the very beginning of the build proces |
19:41.56 | y_morin | kos_tom: OK, I know of that one. |
19:42.47 | y_morin | Log filel is not yet created. To create the log file, we need the install directory, but it requires knowing the proper tuple. |
19:42.55 | y_morin | s/filel/file/ |
19:43.16 | Jacmet | y_morin: you have problems building a toolchain with buildroot? |
19:43.36 | y_morin | Jacmet: now OK, with kos_tom's .config. |
19:43.56 | y_morin | I just tried some default to do a quick build to see if I could tackle bug #851. |
19:44.06 | Jacmet | y_morin: and a normal rm .config; make menuconfig; select arch; save; make doesn't work for you? |
19:44.29 | y_morin | Jacmet: nope. Bails out when build initial (stage 1) gcc. |
19:44.37 | y_morin | Smthg to do with CTOR/DTOR... |
19:45.01 | Jacmet | y_morin: strange - Just normal arm eabi? |
19:45.17 | Jacmet | y_morin: I built that 2-3 times today without problems |
19:45.35 | Jacmet | y_morin: both with uclibc 0.9.30.x and 0.9.31 and gcc 4.3.x / 4.4.x |
19:46.38 | y_morin | Fresh clone -> make menuconfig -> select ARM, uClibc-0.9.30.x -> save -> make |
19:46.42 | y_morin | I'll check again. |
19:47.54 | kos_tom | y_morin: by any change, do you have an already existing ARM toolchain in your PATH ? |
19:48.00 | kos_tom | s/change/chance/ |
19:48.29 | y_morin | kos_tom: Gosh. You're right. Sigh... |
19:48.52 | Jacmet | wee, my debouncing / pulse counter thingy works |
19:50.19 | y_morin | Jacmet: tic tic tic... ;-) |
19:51.49 | kos_tom | y_morin: it might be interfering with the build process. |
19:52.04 | y_morin | kos_tom: I just wiped it out... |
19:52.14 | Jacmet | y_morin: it's for my solar panels, so I can rrdtool'e the output |
19:52.14 | y_morin | and restarted from scratch |
19:52.32 | y_morin | Jacmet: going green? |
19:52.44 | Jacmet | y_morin: yeah, kind of |
19:53.23 | Jacmet | y_morin: our house is ~2 years old, and we tried to do as much "green" as we could (within budget) |
19:55.24 | y_morin | How on earth do I tell git that I want to copy file foo/bar to foo/buz ? |
19:55.57 | y_morin | So I can use foo/bar as a base for foo/buz . |
19:56.09 | Jacmet | y_morin: you don't git figures that out itself |
19:56.50 | y_morin | Jacmet: so, plain cp, followed by git add and git commit. |
19:57.19 | Jacmet | y_morin: yes |
19:59.22 | Jacmet | y_morin: git show -C should normally show that it was a copy after commit |
20:00.19 | Jacmet | y_morin: E.G. cp foo baz; git add baz; git diff -C HEAD |
20:00.33 | Jacmet | diff --git a/Makefile b/Makefile2 |
20:00.33 | Jacmet | similarity index 100% |
20:00.33 | Jacmet | copy from Makefile |
20:00.34 | Jacmet | copy to Makefile2 |
20:01.59 | y_morin | Jacmet: OK Thx! |
20:02.23 | y_morin | kos_tom: Yeah! T'was the other arm toolchain that caused the issue. |
20:02.56 | Jacmet | y_morin: we should probably detect that and warn/error out |
20:04.15 | y_morin | Jacmet: 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.32 | Jacmet | y_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.58 | y_morin | Jacmet: yes, it's better to detect and error out right away, avoids a useless coffee-break! :-] |
20:07.20 | Jacmet | y_morin: ;) |
20:11.57 | CIA-55 | 03vda.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.29 | pentanol | Jacmet there? anyway it's brocken buildroot-2010.02/output/build/gdbserver-6.8/.configured] Error 77 |
20:33.01 | Jacmet | pentanol: strange - it built fine here |
20:34.27 | pentanol | which linux your pc runs? |
20:35.36 | Jacmet | pentanol: debian (64bit) |
20:36.27 | pentanol | hm, I'm on debian i386 |
20:38.26 | Jacmet | pentanol: shouldn't matter |
20:40.09 | *** join/#uclibc dileX (~sd@p5B2EC126.dip.t-dialin.net) |
20:52.19 | pentanol | it 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.32 | pentanol | --target=arm-linux-uclibc |
20:52.45 | pentanol | means rm-linux-uclibc-gcc |
20:52.48 | pentanol | arm* |
20:52.59 | Jacmet | pentanol: and you're sure you no longer have another cross compiler in your path? |
20:53.29 | pentanol | no |
20:53.32 | pentanol | I've not |
20:55.32 | Jacmet | pentanol: sorry, have no idea why it then fails for you |
20:57.38 | pentanol | could you give me output when it start ./configure gdb on your machine? |
20:57.47 | pentanol | and flags.... |
21:01.00 | Jacmet | pentanol: I don't have the build anymore, but the invocation should be exactly as yours |
21:01.11 | Jacmet | pentanol: does you config.log show anything of interest? |
21:02.48 | pentanol | actually trouble with this flags... --build=i386-pc-linux-gnu --host=armv5l --target=arm |
21:02.54 | pentanol | which on yours? |
21:03.34 | pentanol | also it changes arch gsb building |
21:03.37 | pentanol | gdb8 |
21:06.57 | Jacmet | pentanol: 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.05 | CIA-55 | 03rep.dot.nop 07master * r1d0e75b7c05f 10uClibc-website/ (news.html oldnews.html): announce 0.9.31 |
22:04.38 | CIA-55 | 03vda.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) |