irclog2html for uclibc on 2002.08.26

00:24:59anderseeevening ejh
00:25:03anderseeevening sjhill
00:25:08anderseekant tipe
00:25:14aaronlevening andersey
00:25:39sjhillevenin' andersee :)
00:31:22andersee:)
00:31:44anderseeMind giving uClibc a good workout today/tomorrow?
00:31:51anderseeGetting ready for a release....
00:32:07aaronllol
00:32:07aaronlI swore back around 95 to join lk only when Linux gets a IDE maintainer        
00:32:08aaronlwho is not insane. Hasnt happened yet.
00:32:09sjhillsure
00:32:32sjhillaaronl: what do you expect, IDE in and of itself is insane....long live scsi!!!!
00:32:37anderseegoes to look at the latest ranting from Andre
00:35:23anderseesjhill: this release involves some changes to fundamental types, so it not binary compatible...
00:35:38aaronlwhat about VERSIONED SYMBOLS?
00:35:39aaronlducks
00:35:45sjhillno problem, currently we don't need binary compat.
00:36:09sjhilli'm getting ready to switch all of my company's toolchains to uclibc based and rebuild all the rootfs images for uclibc
00:36:12anderseeswings and misses
00:36:20anderseecool
00:36:54anderseeWith this release things are looking very solid.  We even pass the perl and python test suites now w/o any failures.
00:36:56andersee:)
00:37:24sjhillhow are locales?
00:37:29sjhillstill a mess?
00:37:42sjhillhas been away from uclibc for 2 weeks
00:38:57anderseesjhill: wide char is done and works perfectly.  locale support is still in progress -- scheduled to be 100% completed by Nov 1st.
00:39:37aaronlhas anyone made a debian fork based on uClibc yet?
00:39:38aaronli'd run it
00:39:42aaronlglibc gives me the shivers
00:40:00sjhillvolunteers aaronl
00:42:20anderseeaaronl: I suspect that such a project might need the locale support finished first....
00:42:38aaronli don't use locales under debian...
00:42:48aaronlwhen i build things, i prefer --disable-nls
00:42:52anderseeaaronl: that said, I built nearly all of the base system against uClibc last fall...
00:43:00anderseeaaronl: indeed
00:43:16aaronlah, the luxury of being american
00:44:31aaronlmutt was particularly pesky
00:44:39aaronli tried to build it on a 40Mhz RISC system
00:44:44aaronland it demanded libiconv
00:44:58aaronl... which exhausted the disk space in /tmp when i tried to compile it
00:45:21sjhillaaronl: arm or mips/
00:45:23sjhill?
00:45:29aaronlneither
00:45:35aaronlsparc (i THINK that's risc...)
00:45:44sjhillit is
00:45:49aaronli'm bootstrapping gcc on it right now ;)
00:46:04sjhilli think i'd rather eat glass
00:46:24aaronlwell, it's only been running for 7 hours or so ;)
00:49:14aaronli'm trying to find something better to do with that system...
15:02:25mjn3morning.  should be finished the error message stuff shortly
15:03:00anderseemorning
15:03:02anderseecool
15:03:34mjn3wish i knew what the alleged scanf failure was.  :-(
15:03:48anderseeI think I'm going to need to add some additional include guard wrappers around bits/kernel_types.h to avoid gratuitous conflicts with asm/types.h
15:04:17mjn3ok
15:05:13mjn3for the moment, i'm treating the following as unknown errors
15:05:16mjn3sparc:
15:05:29mjn3#define EPROCLIM        67      /* SUNOS: Too many processes */
15:05:29mjn3#define ERREMOTE        81      /* SunOS: Too many lvls of remote in path */
15:05:39mjn3mips:
15:05:41mjn3#define EINIT           141     /* Reserved */
15:05:42mjn3#define EREMDEV         142     /* Error 142 */
15:06:03anderseeHmm.  I think thats fair....
15:06:11mjn3i'm not supplying strings for those.  i think the default generated "Unknown error: ###" is sufficient
15:06:16anderseeI doubt we'll see those too often under Linux
15:06:20mjn3;-)
15:06:54mjn3not the sunos ones.  and the mips ones would be silly.  they don't add any information
15:07:17mjn3so the only extra messages are
15:07:22mjn3#define ECANCELED       158     /* AIO operation canceled */
15:07:28mjn3for mips and
15:07:56mjn3File locking deadlock error
15:08:27mjn3for mips and sparc.  they treat EDEADLK and EDEADLOCK differently
15:10:15mjn3also fixed a problem with strerror() in the process.  for unknown error values, it was returning NULL.  guess i had a neuron fault when i wrote it...
15:20:52mjn3andersee: the mips headers have the following entry:
15:20:56mjn3#define ECANCELED       158     /* AIO operation canceled */
15:22:01mjn3i just checked phoenix and it gives "Uknown error 158" for that one.  so i'm going to ignore it...
15:23:54anderseeok.
15:24:02anderseeSeems fair
15:36:23anderseeGlad to see Miles getting the v850 bits/kernel_*.h files in last night
15:39:01mjn3yep
15:39:56anderseeI guess what I will do is change bits/kernel_types.h to use the same include guard #defines as asm/posix_types.h.  That will avoid the gratuitous conflict and let us avoid broken kernel headers files
16:08:43anderseemjn3: Ok, just checked in the include guard change.  Makes it as safe as usual to include linux/types.h and bits/posix_types.h (i.e. not safe at all, but it works)
16:10:51mjn3andersee: ok.  i'm running some tests to simulate different archs with the errno message stuff.  if everything checks out, i'll commit that shortly
16:13:35anderseecool
16:13:44anderseeLooks like we are just about ready then
16:28:50mjn3hmm.. somethings still not right... also, i still want to rerun the python/perl tests as well as build a threaded perl and run those tests
16:29:22anderseewhats not right?
16:29:49anderseeWith the strerror testing? or something else?
16:29:49sjhillandersee!
16:29:50mjn3the error string stuff.  i still don't have it right...
16:29:54anderseemorning sjhill
16:30:13anderseesjhill: all looking well today on mips?
16:30:46sjhillandersee: i'm just getting started, but i have some toolchain/rootfs questions
16:31:11anderseeok
16:31:22anderseeI should release a gcc 3.2 toolchain today
16:31:50anderseeManuel and I have decided to start migrating the toolchain mods to a form that will allow them to be merged upstream....
16:32:09sjhillthere shouldn't have been any needed changes from 3.1->3.2 for the build script, correct?
16:32:51anderseeyup
16:32:57anderseeJust the gcc version
16:33:09anderseeI think...
16:33:59sjhillwhat do you have in mind as far as migrating toolchain mods? the mods we make are done for uclibc....would they have any bearing for gcc?
16:35:25sjhilli'm going to post a long'ish question on uclibc and building rootfs images, any objections?
16:39:22sjhillQUESTION: I'm running into a problem with conflicting requirements. We want everyone to use a common uClibc based root filesystem image. However, some people want different options compiled into uClibc. I don't want to have people do a 'buildworld' everytime they want to build a rootfs.
16:39:55sjhillI want them to be able to copy a base rootfs image directory, add in their applications and kernel modules and be done.
16:40:26sjhillIdeally, I would like to turn all uClibc options on and then selectively strip the libraries of unwanted features.
16:40:32sjhillAny thoughts?
16:43:46anderseesjhill: re longish question... fine.
16:44:43anderseere uclibc mods for gcc.  Well, they accomodate glibc, and newlib.  So I expect uClibc support (if done cleanly) would be accepted.
16:45:58anderseesjhill: Yes, you can do that (strip uClibc).  You can use mklibs.py from Debian and it should work quite nicely....
16:47:15sjhillandersee: is this how you would handle conflicting requirements for uClibc options and a common base rootfs image?
16:50:06mjn3andersee: i'm about to check in the error message mods.  i was able to check the basic mechanism, but this will need to be checked on mips, sparc, and alpha
16:50:52anderseemjn3: As long as we check mips (i.e. on phoenix), I think we are ok for this release.
16:51:46anderseesjhill: yes.  Given those constraints I would use a single maxed out uClibc build and then use mklibs.py to strip that based on the content of each particular rootfs.
16:54:34anderseemjn3: at this point, alpha and sparc do not have a proper maintainer.  I did the initial ports, but I don't have any hardware and am not overly concerned about them...
16:55:28mjn3andersee: ok
16:57:08anderseeWe care about mips, and mips has a proper maintainer to keep us honest (hi sjhill).  And since I have hardware, checking is easy...
17:00:28sjhillandersee: for my testing, i'm going to use LTP 'ltp.sf.net' compiled against uclibc to see if things are broken
17:00:37sjhillPATH_MAX undeclared
17:01:20sjhillhmm, looks like LTP needs some patching
17:04:21sjhillwho include 'linux/limits.h'?
17:04:27anderseesjhill: It should be in linux/limits.h which is pulled in by sys/param.h...
17:04:47sjhillthx
17:04:50sjhillsys/param.h did it
17:05:33sjhillit looks like  LTP is going to be a real good test for uclibc on MIPS :)
17:07:43sjhillandersee: we have a lot of problems with LTP and uClibc
17:08:43mjn3andersee: do you have uClibc on phoenix?  if so, could you do a cvs up and rebuild and then tell me where the lib is?
17:09:23anderseemjn3: ok, doing that now.
17:11:20mjn3sjhill: doesn't LTP basicly test libc for _glibc_ behavior?
17:11:57sjhillmjn3: not sure, i'm using it for testing stability of my kernel before releasing
17:12:09sjhillandersee: 'mkdtemp' is needed by LTP
17:14:22anderseemjn3: Perhaps some sortof header noise for   and sys_nerr would be appropriate?  i.e. #define sys_errlist "sys_errlist is no longer supported.  Please use strerror()"
17:15:32anderseemjn3: ok, just finished compiling on phoenix.  I did a 'make install' so the toolchain is at /usr/mipsel-linux-uclibc/bin/
17:16:36mjn3ok... regarding the header noise, probably a good idea...
17:19:58mjn3andersee: just tested on phoenix.  mips strerror now works correctly
17:20:34anderseemjn3: you 'da man!
17:20:49mjn3andersee: doing a rebuild so i can rerun the python and perl tests
17:20:55sjhilli'm am soo out of the loop right now
17:22:17mjn3sjhill: when erik was looking at the errno situation, i realized that the errno strings didn't work for the "odd" archs... alpha, sparc, and mips.  so i just fixed strerror and friends to deal with the differences
17:22:36sjhillah
17:23:03mjn3sjhill: one of the reasons i just killed sys_errlist was that mips has a valid errno of 1133!
17:23:22sjhillok, 'mkdtemp' is defined in the 'stdlib.h' header in uclibc, but there is no implementation of it for uclibc, shall i create it?
17:23:36sjhillmjn3: MIPS is weird
17:23:47sjhilli love MIPS, but it's a strange beast
17:27:45anderseesjhill: Hmm.  Looks _exactly_ like mkstemp(), except for a dir not a regular file...
17:28:07anderseesjhill: Should be able to reuse exising code... go for it.
17:28:11sjhillk
17:33:50mjn3andersee: threaded perl build dies pretty quickly with missing readdir64_r
17:35:49anderseemjn3: Hmm.  Gues I implemented readdir_r but forgot readdir64_r
17:37:14anderseemjn3: I'll add readdir64_r right now.  Its a trivial mod of the existing readdir_r
17:39:50mjn3andersee: ok.  python 2.2.1 tests pass with current cvs.  running non-threaded perl build and test now
17:40:44anderseemjn3: I just checked in readdir64_r.c
17:40:49mjn3ok
17:45:27LeeThello. Excuse me for interrupting, but can anyone tell me if there's a channel for general uClinux developers?
17:46:00anderseeLeeT: dunno.  Tried #uclinux?
17:46:16LeeTI didn't see it listed anywhere.. but I'll give it a try. thanks
17:51:33mjn3andersee: unthreaded perl passed all the tests
17:51:46anderseeVery cool
17:51:58mjn3trying a threaded perl build again
17:52:02anderseeWanna do a cvs up to get readdir64_r and try again?
17:52:07anderseek
17:54:00anderseemjn3: I'm running the NIST test now...
17:56:21mjn3andersee: good idea
18:09:47mjn3andersee: threaded perl now builds.  ;-)
18:11:34andersee:)
18:14:38sjhillmkdtemp.c is in 0.9.14...i'm using 0.9.12...i'm SOOO sorry
18:15:33mjn3andersee: seems to be stalled in one of the thread tests...
18:17:01anderseesjhill: It is?  I don't see it...
18:17:16andersee[andersen@dillweed andersen]$ cd CVS/uClibc
18:17:17andersee[andersen@dillweed uClibc]$ grep -r mkdtemp *
18:17:17anderseeinclude/stdlib.h:extern char *mkdtemp (char *__template) __THROW;
18:17:29anderseenada
18:17:52sjhillchecks again
18:23:12mjn3andersee: stalled on 2 of the thread tests.  passed everything else though, although i didn't run the networking tests.  need to do that
18:23:44anderseeHmm.  Can you get straces/ltraces on the stalls?  I may have hosed up some locking somewhere....
18:24:24mjn3i'm running more detailed tests now
18:32:15sjhillandersee: are you planning on releasing 0.9.15 today then/
18:32:17sjhill?
18:33:10anderseesjhill: yup
18:33:16anderseeThats the plan
18:33:24anderseeIts looking quite solid so far...
18:33:33anderseemjn3: NIST test finished
18:33:35andersee$ ./bin/validate | grep FAIL | wc -l
18:33:35andersee     72
18:33:36sjhillbuilds some more
18:34:33anderseemjn3: 72 is much better then the 176 FAILs back in March....
18:36:08mjn3andersee: very true
18:36:42anderseemjn3: glibc gets 66 FAILS...
18:36:51mjn3hmm
18:37:15mjn3andersee: do you want me to just build perl on dillweed for you to look at?
18:38:46anderseemjn3: I bet an ltrace would be good enough.  I'm gonna be doing a touch of kernel hacking once again, so dillweed is gonna be subject to reboots for a while
18:39:36sjhillandersee: wait, you do radeon stuff?
18:42:20anderseesjhill: I work on whatever code happens to piss me off the most.  :-)  That day the radeon frambuffer was irritating me...
18:42:42anderseehas wierd hobbies
18:48:16mjn3andersee: i'm afraid ltrace isn't working out very well here...
18:49:05mjn3andersee: one of the tests is showing the following message in different places in different runs (hey.. what do you expect with threads):
18:49:11mjn3thread failed to start: You need a lock before you can cond_wait at /home/mjn3/work/embedded/perl-5.8.0/lib/Thread/Queue.pm line 76.
19:02:24anderseemjn3: fetching perl-5.8.0.tar.gz now to take a look
19:03:47mjn3andersee: the failure with the other test _seems_ to be related to cond_signal...
19:10:17sjhillandersee: i can even get gcc-3.2 to cross-compile
19:10:27sjhillIn file included from gthr-default.h:1,
19:10:27sjhill                 from ../../gcc-3.2/gcc/gthr.h:98,
19:10:27sjhill                 from ../../gcc-3.2/gcc/unwind-dw2.c:28:
19:10:27sjhill../../gcc-3.2/gcc/gthr-posix.h:37:21: pthread.h: No such file or directory
19:10:46sjhillwhen bootstrapping at stage1, we don't have headers like that!
19:14:46mjn3andersee: hmm... attaching to the tests with gdb... waiting process is at 0x400607dd in __rt_sigsuspend (mask=0xbf3ff958, size=8) at syscalls.c:1460
19:14:46mjn31460    _syscall2(int, __rt_sigsuspend, const sigset_t *, mask, size_t, size);
19:15:34mjn3andersee: but it seems to be waiting on a process that is at 0x40041a18 in __pthread_return_0 () at weaks.c:97
19:15:34mjn397        return 0;
19:16:31mjn3andersee: that the symbol is comming from weaks.c seems very weird...
19:18:05sjhillandersee: nevermind
19:20:23anderseemjn3: using gdb on multi-threaded apps requires a fix to gdb...  gdb tries to use the wrong libthread_db.  That lib is how gdb quesies libpthread state.  Unfortunately, the the path to libthread_db is fixed in gdb at compile time.
19:20:55andersee:(
19:21:12anderseeThat sigsuspend is a sympton of that problem
19:21:19mjn3as if i needed another reason to loathe threads...
19:21:34anderseeindeed
19:24:24mjn3andersee: in any case, looking at the perl code, it stalls at a cond_signal call on a lock
19:26:05mjn3the failing tests are ext/threads/shared/t/cond.t and lib/Thread/Queue.t
19:26:41anderseemjn3: When it says "You need a lock before you can cond_wait" is there code in there attempting to aquire a lock?
19:27:11anderseeis still downloading perl... 9.4 MB and counting....
19:28:05anderseeHow big is this sill thing?
19:28:41mjn311Mb
19:30:00anderseeI'm only getting 6.4 k/sec from cpan
19:31:04mjn3that was the Queue test... i see a lock, but not a cond_wait.  must be from some imported file.
19:38:16mjn3andersee: just so you know, there are some specific things you need to do with the perl config to get it to build...
19:38:33sjhilltlibio.c:699: `sys_errlist' undeclared (first use in this function)
19:38:33sjhilltlibio.c:699: (Each undeclared identifier is reported only once
19:38:33sjhilltlibio.c:699: for each function it appears in.)
19:38:33sjhillmake[1]: *** [tlibio.o] Error 1
19:38:52sjhillummm, you guys have been messing with syserr stuff, any ideas?
19:39:20mjn3sjhill: yes... it his been removed with extreme prejudice...
19:39:38sjhillmjn3: when? i just did a cvs co 1-1/2 hours ago
19:40:10mjn3sjhill: when i fixed strerror and friends.
19:41:23sjhillmjn3: ah, it's the application code....great....so what do i use instead of 'sys_errlist'?
19:42:13mjn3sjhill: what application code?
19:42:39sjhillmjn3: Linux Test Projects (LTP)
19:43:26mjn3sys_nerr and sys_errlist were deprecated a long time ago... they aren't even mentioned as legacy by SUSv3
19:44:20sjhillmjn3: ok, but what should i replace it with?
19:44:24mjn3sjhill: as i mentioned earlier, LTP's libc test seems to be just a test of glibc behavior...  glibc includes everything of course
19:44:26sjhillspends all his time in kernel space normally
19:44:35sjhillhmm
19:45:47anderseesjhill: strerror()
19:46:08anderseei.e. change sys_errlist[errno] to be strerror(errno)
19:46:17sjhillandersee: yup, just found it myself :)
19:46:18mjn3sjhill: apps should be using strerror or strerror_r now... unfortunately there is an issue with strerror_r.  glibc had a version that returns char *.  SUSv3 added a new function (vs v2) that returns int.  that's why i had to play some games in string.h
19:46:18sjhillthx guys
19:47:09mjn3sjhill: yes.  any ref to sys_errlist[errno] should be replaced by strerror(errno), or strerror_r(errno,buf,sizeof(buf))
19:48:55mjn3sjhill: maintaining sys_errlist[] was a problem with different archs.  and mips has an errno of 1133 for EDQUOT
20:39:15sjhillhey BZFlag
20:44:53LeeTdoes anyone know if there's a generic uClinux channel anywhere?
21:33:22sjhillandersee: got a minute?
21:34:32sjhillthese are the remaining functions missing when compiling LTP
21:34:38sjhill`cuserid'
21:34:38sjhill`errx'
21:34:38sjhill`getresgid'
21:34:38sjhill`getresuid'
21:34:38sjhill`setresuid'
21:34:38sjhill`syscall'
21:34:43sjhill`sysctl'
21:34:45sjhill`ulimit'
21:34:47sjhill`valloc'
21:35:17anderseesjhill: syscall() is implemented...  You still using 0.9.12?
21:35:37anderseeAre you testing on mips or x86?
21:37:39sjhillmips
21:37:52sjhillnone of the files get compiled in 'libc/sysdeps/linux/common'
21:38:00sjhillwhich is where a lot of those are
21:38:03anderseeIt looks like ulimit, getresgid, getresuid, setresuid are missing from libc/sysdeps/linux/common/syscalls.c
21:38:15anderseesysctl also
21:38:19sjhillit's worse than that, nothing gets compiled in that directory!
21:38:46sjhilli can't figure out why
21:38:49anderseenothing?
21:38:53sjhillnope
21:39:15anderseedoes a 'make clean; make' on phenix to test mips once again
21:39:26sjhilli'm cross compiling by the way
21:39:28anderseeerr.  phoenix
21:40:29sjhillscreams
21:42:16sjhillmust rpm building must be hosed
21:52:58sjhillandersee: setresuid is commented out in 'syscalls.c'
21:53:05sjhillso are a bunch of the others
21:55:51anderseesjhill: they are not yet implemented...
21:59:43sjhillso, all i have to do is create a _syscallX entry
21:59:48sjhillcool
22:00:06anderseeyup
22:00:30anderseeUnless the syscall is Really Wierd(tm), in which case more may be needed....
22:00:32sjhillgah, 'syscall' eep
22:01:13anderseesyscall() for mips is _mostly_ implemented by libc/sysdeps/linux/mips/__uClibc_syscall.S
22:01:25sjhillwhat's missing that you didn't do?
22:02:08anderseesjhill: see libc/sysdeps/linux/arm/syscall.c for an example of how to do it right...
22:02:13sjhillk
22:02:17sjhillvalloc?
22:02:36sjhillvalloc, cuserid, errx are the only remaining ones i'm not sure about
22:03:13anderseevalloc is a malloc wrapper that ensures that bytes are aligned on a page boundaries.
22:04:19andersee'man 3 cuserid' covers that one
22:04:31sjhillvalloc is not defined from what i can see
22:04:36sjhillbear with me, i'm having a rough day
22:05:47sjhilli can implement cuserid
22:08:39anderseevalloc is indeed not present.  It used to be, but I killed it (implemented)
22:08:48anderseehttp://uclibc.org/cgi-bin/cvsweb/uClibc/libc/stdlib/malloc-930716/Attic/
22:09:02anderseeSee valloc.c and memalign.c in there....
22:09:08sjhillk
22:09:24sjhillerrx is last one
22:09:48anderseeI'm not happy with that implementation though...  It should be done in a malloc implementation independent sortof way.
22:10:06anderseeerrx.h is a variant on err(), from include/err.h
22:10:17sjhillfound it in glibc
22:10:19sjhillhmm
22:11:21sjhilllooks like valloc is the only hard one....
22:11:36sjhilli can get the rest of these implemented today, but you want to release today, right?
22:12:06anderseeI'd like to.  I'd also like to see the implementation before things go in....
22:12:21anderseeI'll be up pretty late tonight...
22:12:21sjhillok
22:12:34sjhilli need to go for a walk before i go postal
22:12:43sjhillambles off
23:50:52ibot is nothing but a knotty-pated thimbleful of tempestuous seagull puke.
23:50:52anderseeibot: insult ibot

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