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.33 | EnigmaCurry | I'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.45 | smithj | EnigmaCurry: ask in #gentoo how to list the files installed in a given package - it is equery something iirc |
03:28.34 | EnigmaCurry | smithj: 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.39 | CIA-10 | 03vda * 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.26 | CIA-10 | 03vda * r18065 10busybox/scripts/defconfig: update defconfig |
13:43.16 | CIA-10 | 03vda * 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.17 | ricko73 | good morning/day |
15:42.29 | ricko73 | I 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.38 | pmjdebruijn | hi |
16:02.54 | pmjdebruijn | is 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.39 | dalias | nptl is such a propagandish name... |
18:00.20 | solar | pretty much |
18:00.37 | dalias | there'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.34 | CruX| | hi all |
18:59.46 | CruX| | i am using latest svn buildroot |
18:59.53 | CruX| | and i'm getting this error |
18:59.54 | CruX| | /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.15 | CruX| | gcc dowsn't generate crt0.o, what's wrong ? |
19:00.49 | CruX| | same problem with arm and mips |
19:04.19 | landley | dalias: the N originally stood for "new". |
19:04.38 | landley | If they renamed it, they waited several years. |
19:04.44 | dalias | :P |
19:05.11 | landley | I thought the main difference boiled down to "uses futexes" vs "does not use futexes". |
19:05.18 | landley | But I haven't looked that closely at it. |
19:08.35 | dalias | that's a stupid performance microoptimization for bad code written without regard to resource contention between threads |
19:08.48 | dalias | the main difference is that nptl actually tries to be posix compliant |
19:08.59 | dalias | with regard to pid and signal semantics for threads |
19:09.08 | dalias | whether it fully succeeds, i dunno |
19:16.00 | landley | dalias: trying to be posix compliant about threads is a _bad_ thing. |
19:16.11 | landley | "No we don't need event semaphores, we'll use event VARIABLES instead." |
19:16.16 | landley | The posix threading standard is brain-damaged. |
19:17.03 | dalias | i agree |
19:17.26 | dalias | cancellation is an abomination too |
19:17.45 | dalias | the same could have been done cleanly and compatibly with signals |
19:21.18 | landley | Theading seems to have originated at Sun, which had totally pathetic fork performance. |
19:22.12 | landley | IBM picked it up for OS/2, as a way of supporting SMP for a single application. |
19:22.24 | landley | But the Unix way of doing this was always just shared memory. |
19:23.00 | landley | Or more often fork and pipes. |
19:43.59 | *** part/#uclibc LetoAtreidesII (n=sepp@p5499E25C.dip.t-dialin.net) |
20:19.53 | dalias | yep |
20:20.01 | dalias | threading is contrary to unix |
20:20.28 | dalias | and it figures that sun was the one to 'invent' and push it |
20:20.37 | dalias | because threading goes hand-in-hand with the java abomination |
20:27.23 | landley | dalias: actually threading was one of the Big New Features of Solaris over SunOS 5. |
20:27.26 | landley | Long before Java. |
20:27.45 | dalias | i just mean the mindsets go together |
20:27.49 | landley | As far as I can tell, threading was introduced with Solaris. |
20:28.18 | landley | And 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.22 | dalias | there seem to be around 4 or 5 major software mindsets |
20:29.08 | dalias | unix, sun/java, windows/mac, lisp, ... |
20:29.51 | dalias | i can't fathom how threading was thought to be a good idea at first... |
20:30.01 | dalias | it sounded like a horrible idea to me the first time i ever heard of it |
20:38.39 | landley | dalias: looking forward to SMP, of course. |
20:39.00 | landley | "How do we program for multiple proessors in a way that can actually work on the one processor most developers actually have?" |
20:39.43 | landley | Plus 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.08 | landley | (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.22 | landley | Not 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.35 | landley | They didn't know asynchronous debugging of race conditions would be a pain in the ass. |
20:42.19 | dalias | unix had already solved it.. |
20:42.43 | dalias | with separate processes and clean ipc mechanisms (pipes, and later unix sockets) |
20:43.50 | dalias | basically 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.07 | landley | dalias: using Unix as a GUI system before about 1992 involved shelling out more than $10k for a "workstation" |
20:52.52 | landley | Also, 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.44 | landley | Also, 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.03 | landley | (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.00 | landley | Now 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.17 | landley | AIX was a weird little sideline for them, screwed up by internal politics and various bad decisions. |
20:55.32 | landley | OS/2 took very little from AIX. |
20:56.04 | landley | And those of us who came up from microcomputers into the PC space really had very little exposure to Unix. |
20:56.52 | landley | And 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.13 | dalias | my point is not gui-specific |
20:57.17 | landley | (Circa 1994, even OS/2 was ahead of any Unix.) |
20:57.53 | dalias | it'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.35 | landley | Between 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.48 | landley | termcap/terminfo is a very strong argument in favor of my position. |
21:00.04 | landley | It's hard to make tn3270 look good, but we managed somehow. |
21:00.25 | landley | (For a form of "we" that predates my personal involvment by rather a lot.) |
21:01.03 | landley | As 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.04 | CIA-10 | 03vda * r18067 10busybox/ (7 files in 4 dirs): (log message trimmed) |
22:16.04 | CIA-10 | next portion of selinux updates: chcon, runcon. From |
22:16.04 | CIA-10 | Yuichi Nakamura <himainu-ynakam@miomio.jp> |
23:06.40 | CIA-10 | 03landley * r18068 10uClibc/libc/ (4 files in 2 dirs): (log message trimmed) |
23:06.41 | CIA-10 | Patch from Al Stone to fix ia64: |
23:06.41 | CIA-10 | The attached patch works around some compilation failures on |
23:13.35 | KhemHome | landley: |
23:13.37 | KhemHome | ping |
23:15.05 | landley | KhemHome: hmmm? |
23:18.17 | KhemHome | I have a Q |
23:18.44 | KhemHome | do you have an arm system running svn trunk uclibc |
23:19.02 | landley | KhemHome: yup. |
23:19.25 | KhemHome | landley: OK |
23:19.26 | KhemHome | cool |
23:19.34 | landley | You 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.48 | landley | If you want to know what it's doing, read build.sh. |
23:19.56 | KhemHome | I saw that if I change my date to say an older date |
23:20.07 | KhemHome | and do touch foo.bar |
23:20.09 | landley | I tried to make it the most readable bash scripts I could, although include.sh undermines that slightly. |
23:20.24 | KhemHome | then foo.bar gets an incorrect timestamp |
23:20.33 | landley | P.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.43 | landley | KhemHome: fun. Lemme see if I can reproduce htat. |
23:20.52 | KhemHome | landley: hello world is almost world |
23:20.57 | KhemHome | ok |
23:21.21 | landley | Yup, touch is saying January 1. |
23:21.33 | KhemHome | you also see it ? |
23:21.35 | landley | That's a bit more than "slightly", I'd say. :) |
23:21.39 | landley | Yup, confirmed here. |
23:21.54 | KhemHome | hmmm and your system is not EABI |
23:21.56 | landley | I haven't built strace for the targets yet, I should add that... |
23:22.02 | landley | OABI here. |
23:22.12 | landley | EABI is a todo item, but at the moment I'm grinding my teeth at PPC. |
23:22.14 | KhemHome | ok that's what I wanted to know |
23:22.19 | KhemHome | it fails on both then |
23:22.23 | landley | Which segfaults in the uClibc exit-from-main code, for me. |
23:22.23 | KhemHome | I have eabi systems |
23:22.46 | landley | KhemHome: 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.55 | landley | Probably should. |
23:22.55 | KhemHome | landley: I will look into firmware seriously once I free up sometime |
23:23.02 | KhemHome | should be next week onwards |
23:23.03 | landley | KhemHome: no rush. |
23:23.15 | landley | I'm doing a 0.2.1 release as soon as I get PPC working. |
23:23.21 | KhemHome | landley: Cool |
23:23.25 | KhemHome | so what is the footprint |
23:23.32 | landley | The 0.2.0 release version has armv4l from before the mmap fix, so gcc doesnt' work yet. |
23:23.35 | landley | But it does in hg. |
23:23.54 | landley | footprint in what units? |
23:24.11 | KhemHome | hmm I mean total static size |
23:24.24 | KhemHome | minimum I mean |
23:24.29 | landley | A tar.bz2 of the arm root filesystem is 11,315,807 bytes. |
23:24.35 | landley | Booted into it (lemme see...) |
23:24.39 | KhemHome | 11 MB |
23:25.08 | landley | du . says 39383 |
23:25.16 | landley | Although that might be a touch rounded up due to block sizes and stuff, not sure. |
23:25.19 | landley | (1k block size.) |
23:25.29 | KhemHome | du -sh |
23:25.31 | landley | And yeah, it's rounded up. Still, reasonable estimate. |
23:25.39 | landley | 38.5M |
23:25.50 | KhemHome | ok |
23:25.50 | landley | Uncompressed. |
23:25.54 | landley | Most of which is gcc. |
23:26.02 | landley | Not much I can do about gcc being a pig. |
23:26.04 | KhemHome | hmm you have native gcc ?? |
23:26.08 | landley | Yeah. |
23:26.10 | KhemHome | why |
23:26.10 | landley | That's the whole point. |
23:26.21 | landley | Building under emulation is an order of magnitude easier than cross compiling. |
23:26.26 | landley | It's slow, but it's reliable. |
23:26.30 | KhemHome | ah ok |
23:26.33 | landley | No lying to ./configure. |
23:26.38 | landley | No trying to get make to do weird things. |
23:26.51 | landley | No two sets of headers, two sets of libraries, installing things at non-default paths and hoping nothing leaks... |
23:27.23 | KhemHome | yeah true |
23:27.50 | KhemHome | so you boot into arm simulator/emulator and then do native build on that ? |
23:27.59 | landley | KhemHome: that's the plan. |
23:28.07 | KhemHome | what do you use for emulator - qemu |
23:28.11 | landley | And I can set up distcc with the cross compiler to have qemu dial out to do some of the heavy lifting. :) |
23:28.20 | landley | KhemHome: of course. |
23:28.23 | landley | Currently 0.9.0. |
23:28.24 | KhemHome | landley: I think that's doable man |
23:28.33 | KhemHome | cool idea |
23:28.51 | KhemHome | so you don't rely on cross compiling much |
23:28.58 | landley | distcc 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.16 | landley | Cross compiling is purely optional, just a performance hack, and strictly limited to the bits it would have a hard time getting wrong. |
23:29.17 | KhemHome | do you know how many arches are supported by qemu does it work for mips,sh,ppc |
23:29.30 | landley | Sorry, I mean cross compiling _after_ creating and booting into the native build environment. |
23:29.44 | landley | That part's cross compiling but it's done on just 7 packages. |
23:29.58 | landley | KhemHome: I've got it working right now on armv4l, mipsel, x86, and x86_64. |
23:30.04 | landley | Sparc's broken for reasons I think are uClibc. |
23:30.09 | KhemHome | yeah I think if qemu is so stable it won't be needed to do cross compiling after you have a system bootstrapped |
23:30.11 | landley | And powerpc is broken for reasons I *%(#&%& know are uclibc. |
23:30.17 | KhemHome | landley: cool |
23:30.40 | landley | KhemHome: cross compiling isn't needed after boot, but it's about 1/5 the native speed. |
23:30.48 | KhemHome | landley: ppc is the only arch that I don't have booted with ppc here |
23:30.53 | landley | Dialing out to distcc to run the cross compiler on the host (outside of qemu) can get some of that speed back. |
23:31.05 | landley | And once youv'e set up distcc on one node, might as well set up more on the local network... :) |
23:31.18 | KhemHome | landley: cross compiling will be faster that's no wonder |
23:31.24 | landley | KhemHome: it's segfaulting on a null pointer dereference in the exit code somewhere. |
23:31.33 | KhemHome | hmm |
23:31.56 | landley | It 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.57 | KhemHome | first thought it must be one of the weak_aliases |
23:32.06 | landley | ./configure, make, preprocessing, and linking are all still done natively. |
23:32.12 | landley | KhemHome: yup. |
23:32.24 | landley | It looks just like the problem I was having on armv4l, except that particular one is fixed. |
23:32.34 | landley | I'm tracking it down again. :P |
23:34.06 | KhemHome | yeah |
23:34.32 | landley | Well, I suspect it won't be before dinner because I'm leaving for that now. |
23:34.40 | KhemHome | can you debug uclibc with debug info on qemu? |
23:39.18 | landley | KhemHome: in theory, yes. In practice, I have very little experience with gdb. |
23:39.29 | landley | Mostly I just stick printfs into stuff. :) |
23:39.48 | KhemHome | ok |
23:39.56 | KhemHome | I was tryin to debug this touch issue |
23:40.11 | KhemHome | it seems some stat structure issue but don't know for sure |
23:40.36 | landley | KhemHome: a couple things to do. |
23:40.59 | landley | Try statically linking the busybox touch binary and running it under qemu-arm user emulation. |
23:41.17 | KhemHome | landley hmmm good idea |
23:41.18 | landley | Then there's good old strace... |
23:41.23 | KhemHome | strace yeah |
23:41.34 | landley | I go to dinner now. I'll try to debug this more when I get back, if you haven't already cracked it. |
23:41.37 | KhemHome | Actually I was booting into Thumb built sytem |
23:41.46 | landley | Seems to be a generic problem. |
23:41.48 | landley | Using kernel 2.6.20? |
23:41.51 | KhemHome | and strace is a bit non cooperating in thumb mode |
23:41.58 | KhemHome | no 2.6.18+ |
23:42.08 | landley | Ok. Data point, I'm using 2.6.20... |
23:42.10 | KhemHome | means base is 2.6.18 plus so many other patches |
23:42.15 | landley | And I'm going to dinner. |
23:42.19 | landley | I'm using 2.6.20 vanilla. |
23:42.20 | KhemHome | ok enjoy |