irclog2html for #uclibc on 20070311

01:04.12*** join/#uclibc wrobbie (n=rob@cm74.kappa84.maxonline.com.sg)
01:31.55*** join/#uclibc KhemHome (n=kraj@adsl-71-146-46-107.dsl.pltn13.sbcglobal.net)
02:20.30*** join/#uclibc ambroseL (n=bjb@ns1.linuxbutler.ca)
03:05.55*** join/#uclibc EnigmaCurry (n=user@host-72-174-221-211.cdc-ut.client.bresnan.net)
03:07.33EnigmaCurryI'm looking for some insight: On ubuntu I have i386-uclibc-linux-gcc, on gentoo I have done "emerge uclibc" but i386-uclibc-linux-gcc (or similar) is nowhere to be found.. ideas?
03:24.45smithjEnigmaCurry: ask in #gentoo how to list the files installed in a given package - it is equery something iirc
03:28.34EnigmaCurrysmithj: thanks, I did that.. it's not installed. However, maybe I found my answer: http://uclibc.org/FAQ.html#wrapper .. does that page mean that i386-uclibc-linux-gcc is somehow deprecated?
07:38.03*** join/#uclibc blindvt_ (n=bf@M794P029.adsl.highway.telekom.at)
10:56.39CIA-1003vda * r18064 10busybox/ (archival/bbunzip.c coreutils/Kbuild coreutils/diff.c): fix buglets found by randomconfig run
11:12.38*** join/#uclibc SpanKY (n=UserBah@pool-151-203-195-204.bos.east.verizon.net)
12:13.17*** join/#uclibc iSteve (i=isteve@beta.vomitron.rozbiju.net)
12:29.26CIA-1003vda * r18065 10busybox/scripts/defconfig: update defconfig
13:43.16CIA-1003vda * r18066 10busybox/ (18 files in 11 dirs): kill superfluous returns at the end of void functions
15:20.55*** join/#uclibc blindvt__ (n=bf@M2386P025.adsl.highway.telekom.at)
15:38.53*** join/#uclibc blindvt__ (n=bf@M2393P024.adsl.highway.telekom.at)
15:41.01*** join/#uclibc ricko73 (n=dhartman@24-196-47-160.dhcp.fdul.wi.charter.com)
15:41.17ricko73good morning/day
15:42.29ricko73I know that uClibc uses /etc/TZ, but is there any reason to include files from /usr/share/zoneinfo on a system that is linked against uClibc
15:58.30*** join/#uclibc pmjdebruijn (n=pmjdebru@pmjdebruijn.xs4all.nl)
15:58.38pmjdebruijnhi
16:02.54pmjdebruijnis it right that uclibc support Native POSIX Thread Library?
16:03.02*** join/#uclibc LetoAtreidesII (n=sepp@p5499E25C.dip.t-dialin.net)
16:28.45*** join/#uclibc landley (n=landley@c-71-199-114-26.hsd1.pa.comcast.net)
16:39.30*** join/#uclibc ambroseL (n=bjb@ns1.linuxbutler.ca)
17:51.50*** join/#uclibc LetoAtreidesII (n=sepp@p5499E25C.dip.t-dialin.net)
17:57.39daliasnptl is such a propagandish name...
18:00.20solarpretty much
18:00.37daliasthere's nothing more "native" about it
18:12.39*** join/#uclibc LetoAtreidesII (n=sepp@p5499E25C.dip.t-dialin.net)
18:21.41*** part/#uclibc ricko73 (n=dhartman@24-196-47-160.dhcp.fdul.wi.charter.com)
18:59.12*** join/#uclibc CruX| (n=CruX@soueza.utc.sk)
18:59.34CruX|hi all
18:59.46CruX|i am using latest svn buildroot
18:59.53CruX|and i'm getting this error
18:59.54CruX|/root/arm/b/build_i686/staging_dir/lib/gcc/i686-elf/3.4.6/../../../../i686-elf/bin/ld: crt0.o: No such file: No such file or directory
19:00.15CruX|gcc dowsn't generate crt0.o, what's wrong ?
19:00.49CruX|same problem with arm and mips
19:04.19landleydalias: the N originally stood for "new".
19:04.38landleyIf  they renamed it, they waited several years.
19:04.44dalias:P
19:05.11landleyI thought the main difference boiled down to "uses futexes" vs "does not use futexes".
19:05.18landleyBut I haven't looked that closely at it.
19:08.35daliasthat's a stupid performance microoptimization for bad code written without regard to resource contention between threads
19:08.48daliasthe main difference is that nptl actually tries to be posix compliant
19:08.59daliaswith regard to pid and signal semantics for threads
19:09.08daliaswhether it fully succeeds, i dunno
19:16.00landleydalias: trying to be posix compliant about threads is a _bad_ thing.
19:16.11landley"No we don't need event semaphores, we'll use event VARIABLES instead."
19:16.16landleyThe posix threading standard is brain-damaged.
19:17.03daliasi agree
19:17.26daliascancellation is an abomination too
19:17.45daliasthe same could have been done cleanly and compatibly with signals
19:21.18landleyTheading seems to have originated at Sun, which had totally pathetic fork performance.
19:22.12landleyIBM picked it up for OS/2, as a way of supporting SMP for a single application.
19:22.24landleyBut the Unix way of doing this was always just shared memory.
19:23.00landleyOr more often fork and pipes.
19:43.59*** part/#uclibc LetoAtreidesII (n=sepp@p5499E25C.dip.t-dialin.net)
20:19.53daliasyep
20:20.01daliasthreading is contrary to unix
20:20.28daliasand it figures that sun was the one to 'invent' and push it
20:20.37daliasbecause threading goes hand-in-hand with the java abomination
20:27.23landleydalias: actually threading was one of the Big New Features of Solaris over SunOS 5.
20:27.26landleyLong before Java.
20:27.45daliasi just mean the mindsets go together
20:27.49landleyAs far as I can tell, threading was introduced with Solaris.
20:28.18landleyAnd it seemed like a good idea for the first few years.  Until people got enough experience with it to figure out why not to do that...
20:28.22daliasthere seem to be around 4 or 5 major software mindsets
20:29.08daliasunix, sun/java, windows/mac, lisp, ...
20:29.51daliasi can't fathom how threading was thought to be a good idea at first...
20:30.01daliasit sounded like a horrible idea to me the first time i ever heard of it
20:38.39landleydalias: looking forward to SMP, of course.
20:39.00landley"How do we program for multiple proessors in a way that can actually work on the one processor most developers actually have?"
20:39.43landleyPlus they were trying to write desktops that don't hang, before ubiquitous networking so they didn't necessarily have a TCP/IP stack to leverage for client/server stuff.
20:40.08landley(THink back in the macintosh days when one app going bye-bye could freeze the whole desktop.  They were asking "how do we avoid this".)
20:40.22landleyNot that it's the only way to avoid it, but it's the kind of thing they were looking for a tool to solve.
20:40.35landleyThey didn't know asynchronous debugging of race conditions would be a pain in the ass.
20:42.19daliasunix had already solved it..
20:42.43daliaswith separate processes and clean ipc mechanisms (pipes, and later unix sockets)
20:43.50daliasbasically the whole era of "crashing window environments" that pervaded the late 80's and 90's was a result of ignorant developers ignoring the lessons of unix...
20:51.07landleydalias: using Unix as a GUI system before about 1992 involved shelling out more than $10k for a "workstation"
20:52.52landleyAlso, how do you "ignore the lessons of Unix" when X11 was released in september 1987 and didn't get to x86 hardware until 1991?
20:53.44landleyAlso, NeWS was technically a much better system than the early X stuff, it's just it was proprietary so the open version won.
20:54.03landley(Saying X is great is a bit like saying the ISA bus was great.  It _won_, but that's not the same thing.)
20:55.00landleyNow Sun specifically ignoring that stuff was deeply stupid since they were Unix from day 1, but somebody like IBM coming up with a non-Unix solution is excusable.
20:55.17landleyAIX was a weird little sideline for them, screwed up by internal politics and various bad decisions.
20:55.32landleyOS/2 took very little from AIX.
20:56.04landleyAnd those of us who came up from microcomputers into the PC space really had very little exposure to Unix.
20:56.52landleyAnd saying Unix is what to look at to solve GUI problems when even Linux still has 2% desktop market share compared to Windows and the Macintosh is an...  "interesting" argument.
20:57.13daliasmy point is not gui-specific
20:57.17landley(Circa 1994, even OS/2 was ahead of any Unix.)
20:57.53daliasit's just that unix had solved the problem of concurrency with a good multitasking model a long time before the bad designs were deployed in windows/mac/etc. guis
20:59.35landleyBetween the PDP-7's display terminal and the early SGI hardware that pluggedinto a Vax, I'm fairly certain they never tried to bolt much of a gui onto the thing.
20:59.48landleytermcap/terminfo is a very strong argument in favor of my position.
21:00.04landleyIt's hard to make tn3270 look good, but we managed somehow.
21:00.25landley(For a form of "we" that predates my personal involvment by rather a lot.)
21:01.03landleyAs the Dec Alpha demonstrates, it's possible to have technology years ahead of its' time and still remain irrelevant until everybody else catches up.
21:11.42*** join/#uclibc ambroseL (n=bjb@ns1.linuxbutler.ca)
21:38.12*** join/#uclibc ambroseL (n=bjb@ns1.linuxbutler.ca)
22:16.04CIA-1003vda * r18067 10busybox/ (7 files in 4 dirs): (log message trimmed)
22:16.04CIA-10next portion of selinux updates: chcon, runcon. From
22:16.04CIA-10Yuichi Nakamura <himainu-ynakam@miomio.jp>
23:06.40CIA-1003landley * r18068 10uClibc/libc/ (4 files in 2 dirs): (log message trimmed)
23:06.41CIA-10Patch from Al Stone to fix ia64:
23:06.41CIA-10The attached patch works around some compilation failures on
23:13.35KhemHomelandley:
23:13.37KhemHomeping
23:15.05landleyKhemHome: hmmm?
23:18.17KhemHomeI have a Q
23:18.44KhemHomedo you have an arm system running svn trunk uclibc
23:19.02landleyKhemHome: yup.
23:19.25KhemHomelandley:  OK
23:19.26KhemHomecool
23:19.34landleyYou can too: http://landley.net/hg/firmware download using a link up top, run "./build.sh armv4l" and then "./run-mini-native.sh armv4l".
23:19.48landleyIf you want to know what it's doing, read build.sh.
23:19.56KhemHomeI saw that if I change my date to say an older date
23:20.07KhemHomeand do touch foo.bar
23:20.09landleyI tried to make it the most readable bash scripts I could, although include.sh undermines that slightly.
23:20.24KhemHomethen foo.bar gets an incorrect timestamp
23:20.33landleyP.S.  By "running" I mean "I got it to build hello world with a native gcc".  I've done very little testing beyond that so far.
23:20.43landleyKhemHome: fun.  Lemme see if I can reproduce htat.
23:20.52KhemHomelandley: hello world is almost world
23:20.57KhemHomeok
23:21.21landleyYup, touch is saying January 1.
23:21.33KhemHomeyou also see it ?
23:21.35landleyThat's a bit more than "slightly", I'd say. :)
23:21.39landleyYup, confirmed here.
23:21.54KhemHomehmmm and your system is not  EABI
23:21.56landleyI haven't built strace for the targets yet, I should add that...
23:22.02landleyOABI here.
23:22.12landleyEABI is a todo item, but at the moment I'm grinding my teeth at PPC.
23:22.14KhemHomeok that's what I wanted to know
23:22.19KhemHomeit fails on both then
23:22.23landleyWhich segfaults in the uClibc exit-from-main code, for me.
23:22.23KhemHomeI have eabi systems
23:22.46landleyKhemHome: I could probably have an EABI system in a couple hours if I sat down and did it, I just haven't yet.
23:22.55landleyProbably should.
23:22.55KhemHomelandley: I will look into firmware seriously once I free up sometime
23:23.02KhemHomeshould be next week onwards
23:23.03landleyKhemHome: no rush.
23:23.15landleyI'm doing a 0.2.1 release as soon as I get PPC working.
23:23.21KhemHomelandley: Cool
23:23.25KhemHomeso what is the footprint
23:23.32landleyThe 0.2.0 release version has armv4l from before the mmap fix, so gcc doesnt' work yet.
23:23.35landleyBut it does in hg.
23:23.54landleyfootprint in what units?
23:24.11KhemHomehmm I mean total static size
23:24.24KhemHomeminimum I mean
23:24.29landleyA tar.bz2 of the arm root filesystem is 11,315,807 bytes.
23:24.35landleyBooted into it (lemme see...)
23:24.39KhemHome11 MB
23:25.08landleydu . says 39383
23:25.16landleyAlthough that might be a touch rounded up due to block sizes and stuff, not sure.
23:25.19landley(1k block size.)
23:25.29KhemHomedu -sh
23:25.31landleyAnd yeah, it's rounded up.  Still, reasonable estimate.
23:25.39landley38.5M
23:25.50KhemHomeok
23:25.50landleyUncompressed.
23:25.54landleyMost of which is gcc.
23:26.02landleyNot much I can do about gcc being a pig.
23:26.04KhemHomehmm you have native gcc ??
23:26.08landleyYeah.
23:26.10KhemHomewhy
23:26.10landleyThat's the whole point.
23:26.21landleyBuilding under emulation is an order of magnitude easier than cross compiling.
23:26.26landleyIt's slow, but it's reliable.
23:26.30KhemHomeah ok
23:26.33landleyNo lying to ./configure.
23:26.38landleyNo trying to get make to do weird things.
23:26.51landleyNo two sets of headers, two sets of libraries, installing things at non-default paths and hoping nothing leaks...
23:27.23KhemHomeyeah true
23:27.50KhemHomeso you boot into arm simulator/emulator and then do native build on that ?
23:27.59landleyKhemHome: that's the plan.
23:28.07KhemHomewhat do you use for emulator - qemu
23:28.11landleyAnd I can set up distcc with the cross compiler to have qemu dial out to do some of the heavy lifting. :)
23:28.20landleyKhemHome: of course.
23:28.23landleyCurrently 0.9.0.
23:28.24KhemHomelandley: I think that's doable man
23:28.33KhemHomecool idea
23:28.51KhemHomeso you don't rely on cross compiling much
23:28.58landleydistcc preprocesses files and sends back the resulting .o to be linked on the master, so all the hard bits of cross compiling happen under the emulator even with distcc.
23:29.16landleyCross compiling is purely optional, just a performance hack, and strictly limited to the bits it would have a hard time getting wrong.
23:29.17KhemHomedo you know how many arches are supported by qemu does it work for mips,sh,ppc
23:29.30landleySorry, I mean cross compiling _after_ creating and booting into the native build environment.
23:29.44landleyThat part's cross compiling but it's done on just 7 packages.
23:29.58landleyKhemHome: I've got it working right now on armv4l, mipsel, x86, and x86_64.
23:30.04landleySparc's broken for reasons I think are uClibc.
23:30.09KhemHomeyeah I think if qemu is so stable it won't be needed to do cross compiling after you have a system bootstrapped
23:30.11landleyAnd powerpc is broken for reasons I *%(#&%& know are uclibc.
23:30.17KhemHomelandley: cool
23:30.40landleyKhemHome: cross compiling isn't needed after boot, but it's about 1/5 the native speed.
23:30.48KhemHomelandley: ppc is the only arch that I don't have booted with ppc here
23:30.53landleyDialing out to distcc to run the cross compiler on the host (outside of qemu) can get some of that speed back.
23:31.05landleyAnd once youv'e set up distcc on one node, might as well set up more on the local network... :)
23:31.18KhemHomelandley: cross compiling will be faster that's no wonder
23:31.24landleyKhemHome: it's segfaulting on a null pointer dereference in the exit code somewhere.
23:31.33KhemHomehmm
23:31.56landleyIt is faster, but it's a purely optional optimization, and carefully limited to the steps that shouldn't be screwed up bit it.
23:31.57KhemHomefirst thought it must be one of the weak_aliases
23:32.06landley./configure, make, preprocessing, and linking are all still done natively.
23:32.12landleyKhemHome: yup.
23:32.24landleyIt looks just like the problem I was having on armv4l, except that particular one is fixed.
23:32.34landleyI'm tracking it down again. :P
23:34.06KhemHomeyeah
23:34.32landleyWell, I suspect it won't be before dinner because I'm leaving for that now.
23:34.40KhemHomecan you debug uclibc with debug info on qemu?
23:39.18landleyKhemHome: in theory, yes.  In practice, I have very little experience with gdb.
23:39.29landleyMostly I just stick printfs into stuff. :)
23:39.48KhemHomeok
23:39.56KhemHomeI was tryin to debug this touch issue
23:40.11KhemHomeit seems some stat structure issue but don't know for sure
23:40.36landleyKhemHome: a couple things to do.
23:40.59landleyTry statically linking the busybox touch binary and running it under qemu-arm user emulation.
23:41.17KhemHomelandley hmmm good idea
23:41.18landleyThen there's good old strace...
23:41.23KhemHomestrace yeah
23:41.34landleyI go to dinner now.  I'll try to debug this more when I get back, if you haven't already cracked it.
23:41.37KhemHomeActually I was booting into Thumb built sytem
23:41.46landleySeems to be a generic problem.
23:41.48landleyUsing kernel 2.6.20?
23:41.51KhemHomeand strace is a bit non cooperating in thumb mode
23:41.58KhemHomeno 2.6.18+
23:42.08landleyOk.  Data point, I'm using 2.6.20...
23:42.10KhemHomemeans base is 2.6.18 plus so many other patches
23:42.15landleyAnd I'm going to dinner.
23:42.19landleyI'm using 2.6.20 vanilla.
23:42.20KhemHomeok enjoy

Generated by irclog2html.pl by Jeff Waugh - find it at freshmeat.net! Modified by Tim Riker to work with blootbot logs, split per channel, etc.