00:05.23 | nitinkg | andersee, how can I configure uclibc for UCLIBC_HAS_SOFT_FLOAT=y |
00:05.38 | nitinkg | I know its in TODO |
00:06.19 | nitinkg | but just curious, if I should hack my way in Rules.mak or command line |
00:09.32 | nitinkg | oops, nm, its __UCLIBC_HAS_SOFT_FLOAT__ |
01:19.33 | *** join/#uclibc ShadowJK (jknutar@hylsy.saunalahti.fi) |
01:28.50 | *** join/#uclibc n2n (nobody@n2n.user) |
03:21.52 | *** join/#uclibc paravoid (paravoid@void.photonics.ece.ntua.gr) |
04:19.33 | *** join/#uclibc tadow (~root@atlrel2.hp.com) |
04:19.52 | tadow | rootwarn? |
04:20.08 | tadow | oh, i am root, nevermind |
04:20.30 | tadow | hey i wanted to thank you guys for the buildroot tools, so far its working great! |
04:20.42 | tadow | I am building a toolchain so I can cross-compile apps for MIPS |
04:22.55 | *** join/#uclibc tadow (~mfisch@atlrel2.hp.com) |
04:23.35 | tadow | anyone still logged on tonight? |
04:34.50 | *** join/#uclibc El-Lotso (~Lotso@218.111.64.208) |
05:36.25 | *** join/#uclibc simmo (~knoppix@adsl-18-27.swiftdsl.com.au) |
05:36.41 | simmo | buildroot gives me an error with dm |
05:37.00 | simmo | rm: cannot remove `/mnt/hda1/buildroot/build_i386/root/usr/lib/libdevmapper.so': No such file or directory |
05:37.38 | simmo | presumably at # Makes libdevmapper.so a symlink to libdevmapper.so.1.00 |
05:37.52 | simmo | in package/dm/dm.mk |
05:38.20 | simmo | buildroot-20050805.tar.bz2 |
05:38.39 | simmo | i'm not sure how to fix the error. |
05:39.58 | simmo | i will probably try to continue build without dm for now |
05:42.34 | simmo | i'm not sure what's a quick way to pick up the build from where i left off, minus dm |
05:43.24 | simmo | i also got some other error/wierdness earlier, fyi |
05:43.53 | simmo | buildroot uclibc says: |
05:43.53 | simmo | Current kernel version is 2.4.31 |
05:43.53 | simmo | Using kernel headers from 2.4.31 for architecture 'i386' |
05:43.53 | simmo | <PROTECTED> |
05:44.08 | simmo | despite i asked to build with 2.6.12 headers, and they were downloaded |
05:44.28 | simmo | earlier i started a build with default headers, dunno if this may be why |
05:44.40 | simmo | or if its supposed to do that? |
05:44.51 | simmo | also |
05:44.53 | simmo | dhcp ftp://ftp.isc.org/isc/dhcp/dhcp-3.0-history |
05:44.53 | simmo | instead of ftp://ftp.isc.org/isc/dhcp |
05:45.05 | simmo | the version of dhcp is moved on the file server |
05:45.17 | simmo | bbl |
05:46.33 | *** join/#uclibc SpanKY (~UserBah@pool-141-154-248-141.bos.east.verizon.net) |
07:23.18 | *** join/#uclibc El-Lotso (~Lotso@218.111.64.208) |
07:28.45 | *** join/#uclibc andersee (~andersee@codepoet.org) |
08:53.16 | *** join/#uclibc alex-ii (~alekseyb@68.146.204.233) |
08:53.18 | alex-ii | Hello |
08:53.59 | alex-ii | What are the main differences between dietlibc and uclibc? Is there documentation available on this matter? |
09:20.09 | simmo | uclibc is more generic i think |
09:20.18 | simmo | and more mature |
09:21.01 | simmo | google |
09:21.49 | alex-ii | generic? |
09:22.00 | alex-ii | I did google. Even more, I did source. |
09:22.26 | alex-ii | the only big problem i noticed with diet is absence of good dynamic linking |
09:23.36 | simmo | ok, then you know more than me |
09:23.43 | simmo | :) |
09:24.06 | simmo | someone has compiled all/most of debian using uclibc i think |
09:25.37 | simmo | http://people.debian.org/~andersee/uwoody/ |
09:25.40 | alex-ii | yes, i read about this in the news -- woody |
09:25.43 | alex-ii | yeah |
09:27.40 | simmo | i am only a wannabe user |
09:29.28 | alex-ii | ok |
09:29.30 | alex-ii | sorry |
09:29.58 | simmo | i answered because i think everyone else here is asleep |
09:30.30 | alex-ii | should be mostly from usa |
09:31.00 | simmo | "In general it tries to provide glibc compatibility so that porting applications to the smaller uClibc is quite easy." |
09:31.12 | simmo | from http://www.ucdot.org/article.pl?sid=02/08/21/1124218 |
09:31.44 | simmo | i think this is the main thing .. uclibc tries very hard and is very successful at that |
09:32.13 | simmo | other small c libs tend to be more aimed at people developing for those libs, and maybe get a bit smaller because of it |
09:33.25 | alex-ii | thank you |
09:35.31 | simmo | what is your impression? have you tried building code with it yet? |
09:35.35 | simmo | it/them |
09:35.46 | alex-ii | i did with diet, not much with uclibc |
09:35.54 | alex-ii | diet appears to be always smaller |
09:36.20 | alex-ii | i haven't seen diet based distros, but apparantly a lot of djbware could run on it without problems |
09:36.43 | simmo | yes, i think diet can only get you so far |
09:37.10 | simmo | and if you need to go further and still stay small, mixing them wouldn't help |
09:37.17 | simmo | since as you mentioned, the static linking |
09:37.43 | simmo | in the long run, dynamic linking means smaller overall size |
09:38.35 | alex-ii | yes --- i know of a single floppy distro usinc uclibc (called nethack) --- no static asm coded binaries |
09:39.57 | simmo | :) |
09:46.59 | simmo | http://www.uclibc.org/toolchains.html |
09:47.13 | simmo | just found this has much more info than the buildroot site |
09:50.04 | andersee | alex-ii: dietlibc is also GPL, vs uClibc's LGPL |
09:50.19 | alex-ii | that's not too big of a difference |
09:50.37 | andersee | alex-ii: dietlibc being GPL prevents all commercial use... |
09:51.06 | alex-ii | yes. so? |
09:51.07 | alex-ii | ;-) |
09:51.27 | alex-ii | the author could negotiate a separate license for $$$ |
09:51.57 | simmo | but when its authors its harder to do that |
09:52.03 | simmo | and gpl usually means authors |
09:52.09 | andersee | alex-ii: nope. The author of dietlibc has included code from others and is thus not exclusive copyright holder |
09:52.20 | alex-ii | aah, more interesting here |
09:52.55 | andersee | uClibc on the other hand is LGPL and I began working on it from day one with the intention of allowing commercial use |
09:54.01 | simmo | :) |
09:54.03 | alex-ii | ok |
09:54.12 | andersee | many many commercial products use uClibc these days |
09:54.21 | alex-ii | could somebody explain me why people hate locale system so much? |
09:54.31 | alex-ii | Is there a better alternative to it? |
09:54.40 | andersee | alex-ii: because it is huge? |
09:54.46 | alex-ii | I noticed the same craze in openbsd |
09:55.02 | alex-ii | isn't it extra 300k for *all* locales in uclibc? |
09:55.51 | andersee | alex-ii: true, due to a great deal of work by mjn3 to eliminate many types of encoding redundancy in the data... |
09:55.54 | alex-ii | and, i could go with only a few kbs if i need only a few locales... |
09:56.19 | alex-ii | so, what's the problem with the system then? |
09:56.50 | alex-ii | the other question: it seems that more assembly is used in dietlibc. why does not uclibc take this approach? |
09:57.08 | alex-ii | (are benefits of assembly simply not worth it?) |
09:57.34 | andersee | alex-ii: because writing asm is hard and often processor specific |
09:57.36 | andersee | i.e. |
09:57.59 | andersee | the most efficient for for a 486 may cause pipeline stalls on a p4 |
09:58.01 | andersee | etc |
09:58.07 | alex-ii | I could say that writing in c is hard too. Same as learning ml after c |
09:58.22 | alex-ii | language gets easy with more experience |
09:58.28 | alex-ii | yes, i understand |
09:58.42 | andersee | using C allows compiler improvements to directly improve the code |
09:59.03 | andersee | using C greatly simplifies makes changes and fixes |
09:59.19 | andersee | using C allows much more code to be shared across architectures |
09:59.58 | alex-ii | were the benefits better in the long run? |
10:00.11 | andersee | using C is the unix way... |
10:00.12 | simmo | uclibc has grown very quickly imho |
10:00.29 | simmo | i think assembly would have slowed that growth significantly |
10:00.40 | simmo | but i am not a coder ;) i just watch many projects |
10:01.16 | andersee | asm code written for the PDP-11 is now worthless, while C code written for the PDP-11 is generally still usable with minor tweaks.... |
10:01.54 | andersee | it has been my goal for uClibc to only use asm when using C is simply not possible |
10:02.04 | alex-ii | simmo: asm is used because it's sometimes more expressive than C. Even more, compiler generated asm is not always the most efficent. |
10:02.20 | simmo | yes |
10:02.22 | andersee | which is an effective strategy for cross arch support |
10:02.29 | alex-ii | the point is that good handcrafted asm if used appropriately could provide big benefits |
10:02.39 | alex-ii | note, i'm not advocating more of its use in uclibc |
10:03.16 | andersee | alex-ii: nobody cares how fast strtok is... The stuff folks care about are memcpy, strcpy, etc |
10:03.17 | simmo | a good approach generally seems to be first write in C then improve key sections using asm replacements |
10:03.44 | andersee | alex-ii: and for those, uClibc does use (optional) platform specifc asm |
10:03.51 | simmo | but keep compatibility with the old C so archs can be ported easily |
10:04.14 | alex-ii | yes, i noticed that asm |
10:04.22 | alex-ii | what about math? |
10:04.36 | alex-ii | (actually, the only question, others are moot) |
10:04.43 | simmo | alex-ii, do you code asm? |
10:04.43 | alex-ii | ..about asm |
10:04.53 | alex-ii | yes, for x86 mostly |
10:05.12 | alex-ii | when i get access to arm, i'll take onto its asm |
10:07.26 | andersee | alex-ii: folk concerned only with x86, and yerning for absolute max hand coded asm performance with min possible size for x86 asm would do well to stick with http://linuxassembly.org/ |
10:08.09 | alex-ii | yeah, x86 is very common now |
10:08.15 | alex-ii | ... and horrible ;-) |
10:08.27 | alex-ii | but, it smells like a flamewar |
10:08.33 | andersee | alex-ii: uClibc has somewhat similar goals, but is intended to be 100% standard compliant, and more flexible, complete, and cross platform |
10:09.16 | alex-ii | diet supports a lot platforms too |
10:09.26 | alex-ii | not so much about standards, indeed, though |
10:09.52 | alex-ii | 100%? it scares me. does it mean bloat would be introduced? |
10:10.08 | andersee | alex-ii: as with everything there are tradeoffs. you pick what is important to you are go with it. |
10:10.54 | andersee | alex-ii: uClibc is configurable. Dont need posix wordexp(), rpc support, etc. fine. Turn those off. |
10:10.58 | simmo | http://www.menuetos.org/ <-- i love this, but it's not very useful |
10:13.16 | alex-ii | that looks very good |
10:13.27 | simmo | yes, it's incredible |
10:13.44 | simmo | but not very portable |
10:13.48 | alex-ii | why is rootfs so big? |
10:13.58 | alex-ii | simmo: ~12 architectures... |
10:13.58 | simmo | rootfs is small |
10:14.02 | alex-ii | 22M? |
10:14.10 | alex-ii | it's big |
10:14.14 | simmo | it has gcc |
10:14.29 | alex-ii | has anybody tried to use a smaller compiler? |
10:15.00 | simmo | well then i think you lose a lot of optimisations, so really would need to use asm a lot |
10:15.10 | simmo | but i don't know many smaller free compilers |
10:15.31 | simmo | . o O (you were made as well as we could make you) |
10:16.07 | andersee | alex-ii: alledgedly tcc works -- http://fabrice.bellard.free.fr/tcc/ |
10:16.57 | andersee | alex-ii: from the dude that does qemu |
10:17.44 | andersee | alex-ii: tcc it small and very fast, though the resulting code is nowhere near as good as what gcc produces |
10:17.55 | alex-ii | "not as good" ? |
10:17.59 | alex-ii | what do you mean |
10:18.37 | simmo | like you were saying re asm vs gcc output |
10:18.48 | alex-ii | ым |
10:18.52 | alex-ii | oops |
10:18.52 | alex-ii | ok |
10:19.32 | andersee | nat as good means if you care much much more about compiler speed than code speed, by all means use tcc |
10:19.51 | andersee | if you care more about code speed, gcc is a much better choice |
10:20.04 | LeaChim | what about code size? |
10:20.12 | andersee | dunno |
10:20.38 | andersee | and tell the rest of us |
10:20.39 | andersee | :-) |
10:21.48 | paravoid | iirc tcc is having one single goal: compile speed |
10:22.08 | alex-ii | what about digitalmars? |
10:22.12 | paravoid | they've managed to make a working Linux system to be compiled on the fly... |
10:22.53 | alex-ii | "on the fly"? |
10:23.19 | simmo | compiles the kernel before booting |
10:23.31 | simmo | it |
10:23.44 | simmo | presumably boots only in a limited range of hw |
10:24.02 | alex-ii | :D |
10:24.03 | simmo | and he mentions only one version of kernel tested |
10:24.11 | simmo | but again, incredible |
10:24.18 | alex-ii | indeed |
10:24.55 | andersee | i.e. bootloader executes tcc, which first compiles the kernel, then boots the newly compiled kernel all in about 15 seconds |
10:25.26 | andersee | not all that useful, but a pretty neat trick |
10:25.37 | alex-ii | wait... but does tcc need to use system calls at all? |
10:25.53 | simmo | http://www.uclibc.org/lists/uclibc/2005-January/010895.html |
10:26.15 | simmo | what is the answer to this question? if i specify 2.6.12 in buildroot, should it compile uclibc with 2.6.12 as well? |
10:26.27 | simmo | i guess i shoulda used a snapshot uclibc ... |
10:26.42 | alex-ii | thank you |
10:28.02 | andersee | simmo: that shouldn't have happened. disconnect between buildroot .config and uClibc .config I suspect |
10:28.46 | simmo | hmm |
10:29.19 | simmo | i am wondering if i should build the last release version of buildroot first, then use that to build a snapshot |
10:29.29 | simmo | or something |
10:29.39 | simmo | lots of variables to untangle when something gets wrong |
10:30.08 | simmo | what is the make target if i want to clean up but leave the downloaded sources intact? |
10:30.33 | paravoid | andersee: so should I/we expect .28 any time soon? :P |
10:30.44 | paravoid | andersee: I want to create usarge before september |
10:31.13 | simmo | :) |
10:31.16 | andersee | paravoid: I've stated it a few times, but the current plan is for mid august |
10:31.28 | paravoid | andersee: oh, I'm sorry, haven't seen it. |
10:31.57 | andersee | np |
10:32.14 | alex-ii | thank you |
10:32.19 | alex-ii | i have to go now |
10:32.20 | alex-ii | cu later |
10:32.56 | paravoid | andersee: I'm trying to figure out a way to build usarge (or etch/sid for that matter) easily every time uclibc's ABI breaks |
10:33.06 | paravoid | andersee: something like buildroot but for Debian :) |
10:33.14 | *** join/#uclibc LeaChim (~LeaChim@host81-138-44-139.in-addr.btopenworld.com) |
10:33.28 | andersee | paravoid: some work to that effect using has been done using scratchbox |
10:33.33 | paravoid | andersee: maybe cross-compiling with a proper toolchain in a standard Debian... |
10:33.33 | andersee | err |
10:33.39 | andersee | paravoid: some work to that effect has been done using scratchbox |
10:34.10 | andersee | http://www.scratchbox.org/ |
10:34.53 | andersee | paravoid: see this paper |
10:34.59 | andersee | paravoid: http://64.233.179.104/search?q=cache:_2XV99VJ-8MJ:scratchbox.org/~tsavola/crocodile-debconf5.pdf+scratchbox+bootstrap+debian&hl=en |
10:35.11 | paravoid | arg |
10:35.22 | paravoid | I wanted to make it to dc5 soo much :/ |
10:38.14 | paravoid | thanks, seems very helpful :) |
10:38.39 | andersee | http://viewcvs.scratchbox.org/cgi-bin/viewcvs.cgi/crocodile/ |
12:27.35 | JockeHome | trying to run ltp on ppc, but ltp needs getopts. Where do I get getopt? |
12:28.02 | JockeHome | Do I need perl also? |
12:49.26 | JockeHome | found getopts, now I get: |
12:49.33 | JockeHome | ./runltp -i 1024 -m 128 -p -q -l /tmp/resultlog.80 -d /root/ltp-full-20050707/ |
12:49.49 | JockeHome | [: /root/ltp-full-20050707/runtest/syscalls: unknown operand |
12:49.49 | JockeHome | FATAL: missing scenario file /root/ltp-full-20050707/runtest/syscalls |
12:51.56 | JockeHome | looks like [ isn't working: |
12:52.04 | JockeHome | > [ |
12:52.20 | JockeHome | -sh: Cannot fork |
13:01.35 | JockeHome | will try latest busybox |
14:05.03 | solar | [ starts a subshell? |
14:57.34 | JockeHome | solar: looks like it, but now it seems like ltp is doing something that corrupts my system |
15:00.38 | JockeHome | hmm, ltp causes lots of .nfsxxxxxxxx files to be created |
15:14.12 | *** join/#uclibc tadow (~mfisch@atlrel2.hp.com) |
15:19.03 | JockeHome | I get this when I run ltp and after that my system is nonfuctional: |
15:19.07 | JockeHome | [: /root/ltp-full-20050707/runtest/syscalls: unknown operand |
15:19.07 | JockeHome | FATAL: missing scenario file /root/ltp-full-20050707/runtest/syscalls |
15:20.14 | JockeHome | maybe a bug in uClibc that corrupts something? |
15:49.14 | *** join/#uclibc GyrosGeier (~geier@honey.kvedulv.de) |
17:03.16 | *** join/#uclibc mfisch (~mfisch@atlrel2.hp.com) |
17:03.58 | mfisch | has anyone built the au1500 buildroot before? |
17:22.08 | *** join/#uclibc bl0w3r (~elven@200.180.51.64) |
17:22.38 | *** join/#uclibc tony (~tony@host81-151-45-186.range81-151.btcentralplus.com) |
17:23.22 | tony | hi |
17:49.13 | bl0w3r | how can I activate the CGI from httpd ? |
17:49.45 | *** join/#uclibc El-Lotso (~Lotso@218.111.64.208) |
17:49.46 | bl0w3r | httpd -p 3120 -h /www -c /etc/httpd.conf -r "Autenthicate" |
17:50.00 | bl0w3r | and when the URL .cgi its call he can download! |
17:55.58 | *** join/#uclibc agentgates (~tony@host81-151-45-186.range81-151.btcentralplus.com) |
17:57.29 | bl0w3r | -d ? -e ? |
18:11.26 | *** join/#uclibc JockeHome (~JockeHome@84.217.84.230) |
22:32.58 | *** join/#uclibc tadow (~timf@c-24-9-53-57.hsd1.co.comcast.net) |
22:33.10 | tadow | hey all |
22:35.33 | tadow | any gotten buildroot to work for MIPS recently? |
22:36.02 | mjn3 | i've done at least 10 mipsel buildroot builds in the past 2 weeks |
22:36.14 | tadow | cool |
22:36.20 | tadow | its working for me, sorta |
22:36.57 | tadow | the compiler it builds is making Big Endian binaries, unfortunatel |
22:37.35 | mjn3 | when was the last time you updated buildroot. there was a problem like that some time back. but that was perhaps 2 months ago |
22:37.48 | tadow | downloaded last night's edition |
22:37.56 | tadow | triple checked my settings.... |
22:38.31 | tadow | think an older edition might work? |
22:38.34 | mjn3 | no |
22:38.39 | mjn3 | i'm using current |
22:39.07 | tadow | could you email me your config (or put it somewhere), I would like to diff mine |
22:41.53 | tadow | one idea |
22:41.55 | mjn3 | if your buildroot .config has BR2_mipsel=y and your uClibc .config has ARCH_SUPPORTS_LITTLE_ENDIAN=y, then you should be set |
22:42.08 | tadow | lemme check |
22:42.43 | tadow | brb |
22:46.06 | *** join/#uclibc tadow (~mfisch@atlrel2.hp.com) |
22:46.38 | tadow | mjn3, I have BR2_mips=y |
22:46.42 | tadow | not mipsel=y |
22:47.07 | vapier | did you select 'mipsel' in buildroot ? |
22:47.17 | tadow | sorry |
22:47.31 | vapier | Target Architecture (mipsel) ---> |
22:48.04 | tadow | btw, this tool is cool |
22:48.54 | tadow | I did find one bug though |
22:49.14 | vapier | i'm sure there's a bunch |
22:49.18 | tadow | in the menu, where it asks "How many jobs to run similtaneously" |
22:49.31 | tadow | it defaults to 1, and I cannot use the "Backspace" key |
22:49.38 | tadow | so when I try to change it to 2, I get 12 |
22:49.55 | vapier | sounds like a terminal issue |
22:49.59 | tadow | hmm |
22:50.05 | tadow | just using an xterm |
22:50.20 | tadow | anyway, try it next time you do a build |
22:50.24 | tadow | not a big deal |
22:50.39 | vapier | i just test it, works fine |
22:50.45 | vapier | tested |
22:50.48 | tadow | ok, my fault then |
22:51.35 | tadow | I selected mipsel |
22:56.45 | tadow | well vapier, I am heading to a picnic, I will let you know if it works. Thanks for the info |
22:56.51 | tadow | thanks mjn3 too |
22:57.37 | *** part/#uclibc tadow (~mfisch@atlrel2.hp.com) |