00:12.49 | CIA-8 | 03psm * r12174 10uClibc/libc/string/ (6 files in 6 dirs): Disable multi build on asm files. i386/powerpc could be used if the source is splitted up |
00:28.10 | psm | mjn3: ping |
01:07.59 | CIA-8 | 03psm * r12175 10uClibc/libc/string/Makefile.in: Enable multi, because the arch specific versions are non-multi now |
01:24.37 | *** join/#uclibc landley (n=landley@rrcs-24-173-214-90.sw.biz.rr.com) |
01:27.50 | landley | Why does lash's command interpreter parse escape sequences? (Ala \n?) |
01:28.50 | landley | Ok, why does it attempt to parse them, and fail? |
01:28.59 | landley | (Try "echo hello\tworld" |
01:29.06 | landley | or echo hello\n |
01:29.14 | landley | and contrast that with echo hello\n\n\n |
01:29.32 | landley | Which for some reason gives hello |
01:29.32 | landley | lash: tcsetpgrp: Operation not permitted |
01:29.41 | landley | Right... |
01:33.27 | landley | It's actually good to know there _is_ a bb_process_escape_sequence(), though. |
01:33.30 | landley | Sed should be using it... |
01:57.55 | landley | Ah, remembering fun sed corner cases... |
01:57.59 | landley | echo "henry" | sed 's\nr\aa\' |
01:58.07 | landley | Produces "heaay" |
01:58.19 | landley | Because \ is the delimeter, so \n and \a don't get parsed... |
01:58.48 | landley | The sequencing of this stuff was _finicky_, and I'm about to perturb it... |
01:58.54 | landley | Time to make a test case... |
02:02.37 | landley | I'm trying to remember what sed -i - is supposed to do... |
02:02.43 | landley | Modify a file called "-", I suspect... |
02:07.26 | landley | Darn it, busybox sed is failing the "henry" test at present... |
02:07.39 | landley | So the sequencing is already screwed up. Toldja it was tricksy... |
02:24.50 | *** join/#uclibc thraxisp (n=thraxisp@ottawa-hs-64-26-147-213.d-ip.magma.ca) |
03:19.56 | *** join/#uclibc ambroseL (n=bjb@ns1.linuxbutler.ca) |
04:43.20 | *** join/#uclibc varun (n=varun@CPE-144-137-111-76.nsw.bigpond.net.au) |
04:43.52 | varun | hey anyone has idea how can i use ncurses with uclibc? |
04:44.17 | varun | how can I build it so that I can compile my code using ncurses in busybox |
04:44.21 | varun | ??? |
04:44.33 | varun | I don't want to use buildroot |
04:44.59 | varun | anyone there? |
05:02.11 | *** join/#uclibc enerv (n=enerv@201008202191.user.veloxzone.com.br) |
05:14.39 | varun | any one there |
05:29.26 | *** join/#uclibc enerv (n=enerv@201008202191.user.veloxzone.com.br) |
06:03.21 | mjn3 | varun: if you don't want to use buildroot, fine. but that isn't stopping you from seeing how buildroot does it and then doing it yourself |
06:04.57 | varun | hmm |
06:05.21 | varun | thanks for that great help |
06:06.32 | mjn3 | you want personalized help, feel free to offer me a contract. you're already using thousands of lines of my code so i wouldn't be complaining if i were you |
06:08.06 | mjn3 | one of buildroot's purposes is to show of how to use uClibc with a number of packages |
06:08.25 | mjn3 | saves answering the same question millions of times |
06:10.15 | varun | smartboy |
06:10.32 | varun | this is my contract .. |
06:11.08 | varun | but neways will thought abt it |
06:52.31 | *** join/#uclibc landley (n=landley@adsl-64-123-8-7.dsl.austtx.swbell.net) |
06:58.48 | landley | Sniffle. Broke my beautiful test suite... |
06:58.55 | landley | (Putting the pieces back together...) |
06:59.07 | landley | Admittedly, with new design issues... |
07:06.20 | landley | ... Tumbleweeds drift past. Sound of wind blowing... |
07:14.41 | *** join/#uclibc _cow (n=cow@M966P018.adsl.highway.telekom.at) |
07:25.14 | landley | Hello. |
07:25.52 | landley | My recent foray back into the land of busybox sed has reminded me I need to beat the sed test suite into submission. |
07:26.16 | landley | Which reminded me that the testsuite code I was doing kinda got hijacked when I let it stall... |
07:26.27 | landley | So I'm trying to shoehorn its original intent back in. |
07:26.46 | landley | Got testing.sh redone, now I need to bang on runtests to move what belongs there. |
07:26.57 | landley | Then clean up the individual .tests files to the new notation. |
07:27.06 | landley | What I do for fun on a sunday evening... |
08:28.13 | *** join/#uclibc vrm (n=vrm@248.55.101-84.rev.gaoland.net) |
08:39.50 | cow`` | landley, would the combine patch be acceptable if i'd beat it into producing same-sized code as before for gcc-3.4 ? |
08:50.57 | CIA-8 | 03landley * r12176 10busybox/testsuite/ (8 files): (log message trimmed) |
08:50.58 | CIA-8 | Fix the test suite so that individual *.tests files can be run ala |
08:50.58 | CIA-8 | <PROTECTED> |
08:51.19 | landley | cow: for 1.1, gcc 3.2 and 3.3 are still going to be used by people. |
08:51.35 | landley | You'd have to make it optional, somehow. |
08:51.50 | landley | And the added complexity for an optional feature would be a hard sell. |
08:52.15 | landley | For 1.2, we can basically say "3.4 and up are the recommended compilers" and accept a size penalty for 3.2 and 3.3. |
08:52.19 | landley | But not for 1.1. |
08:52.37 | landley | On a side note: do you think you can get it to produce same-sized code for 3.4? |
08:52.58 | landley | (Keep in mind that I want to ship 1.1 by the end of the year. There will probably be a -rc1 in early December. Then in January, we open the -devel tree for 1.2.) |
08:53.07 | landley | So I'm only suggesting holding off for about two months. |
08:55.47 | cow`` | landley, i could look into making it equal size for 3.4, i didn't do so yet, just concentrated on 4.1, as that's the one im most interrested in. |
08:56.00 | *** join/#uclibc psaksa (n=pate@ip212-226-134-137.adsl.kpnqwest.fi) |
08:56.09 | landley | Is 4.1 out yet? |
08:56.10 | cow`` | landley, holding it off until 1.2 is out is basically ok with me |
08:56.19 | landley | Until 1.1 is out, you mean. :) |
08:56.40 | cow`` | landley, no, not yet. But from what i got, it ought to go into freeze later this year |
08:56.58 | cow`` | landley, yes right. until 1.1 is out |
08:57.12 | landley | Cool. Just wondering if I needed to upgrade my Firmware build to a whole new compiler so quickly... |
08:58.18 | landley | I hath gotted the test suite beatened back into shape. Forsooth. |
08:58.30 | landley | (I just confused everybody on the list who doesn't have english as their first language.) |
08:58.30 | cow`` | landley, i only put emphasis on tweaking flags a bit for 4.1, and i'm almost certain that some of those tweaks did actually hurt the 3.x series (strength-reduce, for one, also the last checked entry which is related to strength-reduce) |
08:58.32 | landley | (Badly.) |
08:58.55 | landley | Keep in mind that in 3.2 at least, some of the flags are actually _buggy_. |
08:59.10 | landley | We're going to need to introduce a "platform.h" file at some point. |
08:59.30 | landley | I'm starting to stumble across #ifdef NEWLIB crap in various parts of busybox. (#ifdef uclibc was bad enough...) |
08:59.37 | landley | We need to bury that in header files. |
09:00.03 | landley | I'm not sure how we'd go about doing something similar for makefiles, but you get the general idea... |
09:00.28 | landley | (And yes, I've stumbled across #ifdef glibc, too. Or perhaps it was GNU_C.) |
09:06.35 | CIA-8 | 03landley * r12177 10busybox/testsuite/TODO: It was a bit out of date. |
09:09.24 | landley | Time to wander home, the coffee shop's closing up. :( |
09:09.31 | landley | (It used to be 24 hours. Mope. Sulk. Pout...) |
09:12.55 | *** part/#uclibc cow`` (n=cow``@chello213047219050.surfer.at) |
10:10.18 | Zta | Hm, I have a clock somewhere that's running too fast. |
10:11.00 | Zta | About ever 60 secs in real life, my system has gained 2 secs. |
10:11.10 | Zta | Now I'm trying to debug this. |
10:11.42 | Zta | The crystal clock on board will most likely proove to run as expected. |
10:11.59 | Zta | But how is that clock ever handed to Linux? |
10:12.48 | Zta | I use UBoot. Isn't it UBoot that tells Linux how fast the clock is? That converts the clock to Linux' 100 HZ? |
10:12.58 | Zta | Can anyone please help? |
10:13.41 | Zta | Can I see or read the clock configuration from UBoot in its prompt or when booting? |
10:15.08 | Zta | Is there any useable information from Linux itself (/proc/time-or-something?), or is it completely lost, once UBoot has lied to it about the clock on the outside world? |
12:01.11 | ashes | the operating system can't keep time |
12:04.34 | Zta | How does Linux know how fast the external clock runs? |
12:04.38 | Zta | Where do I configure that? |
12:05.16 | ashes | there's no way for linux to know whether the clock is running fast or not |
12:05.45 | ashes | you should run ntpd to sync the clock with an outside source |
12:22.22 | Zta | Um.. |
12:22.31 | Zta | I am talking about hardware here |
12:22.56 | Zta | linux/include/asm-arm/arch-at91rm9200/time.h'ish |
12:45.09 | *** join/#uclibc Masta-G (n=unix@5355D7B6.cable.casema.nl) |
12:45.17 | *** join/#uclibc prpplague (n=billybob@200.50.80.24) |
12:49.15 | Masta-G | latest uclibc cvs is still broken for sh |
12:49.18 | Masta-G | <PROTECTED> |
12:49.18 | Masta-G | ../../libpthread/linuxthreads/libpthread_so.a(attr.os): In function `__pthread_attr_setstacksize': |
12:49.18 | Masta-G | : undefined reference to `__pthread_max_stacksize' |
12:49.18 | Masta-G | ../../libpthread/linuxthreads/libpthread_so.a(attr.os): In function `__pthread_attr_setstacksize': |
12:49.18 | Masta-G | : undefined reference to `__pthread_init_max_stacksize' |
12:49.19 | Masta-G | make[3]: *** [../../lib/libpthread.so] Error 1 |
12:49.21 | Masta-G | make[3]: Leaving directory `/home/mastag/dc/buildroot/toolchain_build_sh4/uClibc/libpthread/linuxthreads' |
12:49.23 | Masta-G | make[2]: *** [_dir_linuxthreads] Error 2 |
12:52.18 | Masta-G | not using the latest snapshot of uclibc will work though |
13:09.43 | prpplague | is andersee the only one actively reviewing issues for buildroot? |
13:15.27 | *** join/#uclibc ade_br (n=ademar@200.222.15.249) |
13:26.01 | *** join/#uclibc psm (n=mps@host-6.mikroweb.hu) |
13:53.20 | prpplague | vapier: don't suppose you've had a chance to re-look over that patch submission for the arm variants additions |
14:03.52 | *** join/#uclibc Negative[work] (n=negative@82.204.238.89) |
14:08.17 | *** join/#uclibc sjhill (n=sjhill@eth13.com-link.com) |
14:18.54 | psm | sjhill: ping |
14:22.48 | sjhill | psm: pong |
14:23.42 | psm | how much have you change for nptl directly related to files in current uClibc svn ? |
14:23.54 | psm | less Makefile* |
14:24.09 | sjhill | every filed in ldso/ldos and ldso/lidbl |
14:24.23 | sjhill | probably 10 files in 'include' |
14:24.47 | sjhill | probably another 10 or 12 files in the libc code |
14:25.00 | sjhill | obviously the entire libpthread/nptl directory is brand new |
14:25.31 | psm | the newly added files are not important, only the changed ones |
14:25.57 | sjhill | k |
14:26.32 | sjhill | the kicker is that there are files in libpthread/nptl that are actually compiled in libpthread/nptl, but are linked in to libc |
14:27.34 | psm | this should be probably done also in linuxthreads I think, now libc code is "polluted" w/ some weaks to overcome this |
14:28.23 | psm | how have you solved this (to add files from nptl to libc , where should I look ? |
14:29.00 | sjhill | hold on |
14:30.38 | psm | if you add your changes to the mainline files, I could try to make you the needed support in new build system ( I am using code currently that goes to ldso and libc.a , so the one for nptl shouldnt be a problem as well) |
14:32.23 | sjhill | libpthread/nptl/Makefile |
14:32.40 | sjhill | look for the 'obj.pthread.ar' and 'obj.pthread.so' targets |
14:33.10 | sjhill | also, the AR_LIBP_CSRC, SO_LIBP_CSRC, etc. |
14:34.04 | sjhill | those targets are called by 'libc/Makefile' |
14:34.11 | sjhill | those two files will show you how i did things |
14:34.27 | sjhill | there are 4 or 5 levels of directories in nptl that have objects |
14:34.34 | sjhill | err, maybe just 2 or 3 |
14:39.53 | sjhill | psm: find everything okay? |
14:57.33 | psm | sjhill: what should be ok? |
15:04.25 | psm | sjhill: *routines = means <routine>.c source files ? |
15:05.32 | sjhill | yes |
15:07.27 | psm | the only diff between AR_LIBP and SO_LIBP are static/shared-only-routines and pt-allocrtsig or SO_LIBP are built w/ -DSHARED and AR_LIBP w/o ? |
15:07.49 | sjhill | that's possible |
15:07.58 | sjhill | i'd have to look through all of the makefiles in nptl |
15:12.15 | psm | I think you meant AR_LIBC and SO_LIBC (not LIBP) |
15:14.55 | *** join/#uclibc __cow (n=cow@M958P017.adsl.highway.telekom.at) |
15:23.30 | psm | sjhill: I wonder why the only file built w/ -DNOT_IN_libc is pthread_atfork.c |
15:25.47 | psm | not true, havent looked at Rules.mak |
15:30.01 | sjhill | down the road, it may be possible to simplify the compile flags |
15:30.14 | sjhill | a lot of those trigger different things in header files |
15:30.27 | sjhill | the dependencies are horrific to say the least |
15:30.43 | sjhill | the progression will be to eliminate the 'nptl/compat' directory first |
15:30.47 | sjhill | and then address the compile flags |
15:31.00 | psm | why do you have the clone/vfork asm files in there? |
15:31.13 | sjhill | probably because i have not deleted them |
15:31.22 | sjhill | i have private todo list that is not on my website |
15:31.27 | psm | well, due to -DSHARED been used in pthreadP.h, almost everything has to be built twice |
15:31.34 | sjhill | yep |
15:33.20 | sjhill | i highly suggest you go with what is my makefiles and not try to optimize things right now |
15:33.31 | sjhill | the stuff is going to change again before i finish |
15:41.02 | *** part/#uclibc uriahheep (n=alexis@toronto-HSE-ppp4169464.sympatico.ca) |
15:41.38 | *** join/#uclibc thraxisp (n=thraxisp@ottgate.precidia.com) |
16:13.03 | *** join/#uclibc tchan (n=tchan@lunar-linux/developer/tchan) |
16:20.02 | *** join/#uclibc mjn3-work (n=mjn3@h-66-134-116-110.dnvtco56.covad.net) |
16:20.57 | psm | mjn3-work: ping |
16:27.14 | mjn3-work | psm: hey |
16:28.17 | psm | mjn3-work: hi, was libc/misc/pthread/weaks.c created by you? |
16:29.29 | sjhill | blame Canada^H^H^H^H^H^H andersee |
16:30.46 | psm | sjhill: am I right, that this could need a similar treatment as you do w/ nptl LIBC/LIBP so that files get compiled into libc instead of libpthread? |
16:30.53 | *** join/#uclibc andersee (n=andersee@codepoet.org) |
16:31.08 | psm | when you speak of the wolf ;) |
16:31.23 | sjhill | psm: yes, i had to modify that file |
16:31.35 | sjhill | but it's pretty much all andersee's fault |
16:33.43 | psm | mjn3-work: is the comment in libc/string/wstring.c about not doing any changes to this file valid currently too ? |
16:36.15 | mjn3-work | don't worry about it. a haven't even looked at elks in ages so i'm not worried about it building for that anymore |
16:43.24 | mjn3-work | sjhill: does nptl support priority inheritence protocol attributes for mutexes? that would be PTHREAD_PRIO_INHERIT |
16:46.22 | andersee | sjhill: morning |
16:46.30 | andersee | my fault eh? |
16:47.01 | andersee | :-) |
16:50.01 | psm | are the lines 24-25 necessary in libc/misc/pthread/weaks.c and if yes, do they have to use __P ? |
16:56.12 | sjhill | mjn3-work: don't know. i haven't had to go to that level yet |
16:56.26 | sjhill | mjn3-work: grep through the nptl directory on glibc and it it's in there, then yes :) |
17:27.22 | *** join/#uclibc waldi (n=waldi@bblank.thinkmo.de) |
17:46.02 | *** join/#uclibc nitinkg (n=ngupta@gateway-1237.mvista.com) |
18:11.59 | *** join/#uclibc woglinde (n=woglinde@e178099249.adsl.alicedsl.de) |
20:44.05 | enerv | psm, hello |
20:44.30 | psm | hi |
20:44.43 | enerv | psm, http://rafb.net/paste/results/RlGt6s25.html |
20:45.33 | psm | I have seen that already ... |
20:45.38 | psm | gcc? |
20:46.19 | enerv | psm, http://rafb.net/paste/results/XdF0AE46.html |
20:47.01 | psm | you should apply the buildroot patches to gcc, then try again |
20:47.14 | psm | also to binutils |
20:47.53 | psm | target i486-linux-gnu means glibc |
20:48.41 | enerv | psm, which the sequence to create toolchain? uClibc binutils to after GCC? |
20:48.54 | psm | see what buildroot does, it can create it for you |
20:49.22 | psm | normally binutils, headers, gcc, uclibc |
20:50.59 | enerv | psm, hnnn, thanks maybe this is problem. i'm constructing toolchain for Debian |
20:51.45 | psm | debian does not include uclibc related patches... |
20:52.43 | enerv | psm, yes, but i'm packing together patchs buildroot |
20:52.50 | enerv | gcc, binutils |
20:53.24 | enerv | psm, binutils-i386-uclibc-cross_2.16.1-1_i386.deb its ok |
20:53.51 | psm | binutils has gotten most of the uclibc related patches upstream |
20:54.28 | enerv | psm, hnnn good... but i need this now, for dd's working in new plataform |
20:54.51 | enerv | after i'm concert this |
20:55.08 | psm | but not in 2.16.1 |
20:55.50 | enerv | why? |
20:56.15 | psm | it is in the hjl versions probably from 2.16.91.0.1 up |
20:57.21 | enerv | psm, hnnn no problem :) for the time being I go using patchs of buildroot |
21:05.39 | enerv | psm, thanks psm |
21:07.44 | psm | I would rather use gcc-3.4.4 |
21:08.11 | psm | that is far more tested then gcc-4 |
23:15.15 | *** join/#uclibc _cow (n=cow@M957P031.adsl.highway.telekom.at) |
23:19.51 | CIA-8 | 03vapier * r12178 10uClibc/libc/sysdeps/linux/sparc/sys/trap.h: old header file |
23:20.09 | CIA-8 | 03vapier * r12179 10uClibc/libc/sysdeps/linux/ (alpha/bits/types.h sparc/bits/types.h): use the common/bits/types.h since it has proper 64bit support now |
23:41.12 | CIA-8 | 03vapier * r12180 10uClibc/libpthread/linuxthreads/ (internals.h pthread.c): implement __pthread_init_max_stacksize() which is required for FLOATING_STACKS |