| 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 |