| 00:00.42 | jbit | if an applicaiton uses iconv for character set handling and iconv is disabled then big5 will show up as junk on a utf8 system |
| 00:01.04 | freezi | i'm making a livecd, that is for web stuff mostly. links, httpd, X, pidgin, firefox. but i have people in china, usa, denmark, sweden, italy, using it |
| 00:01.08 | jbit | also without iconv reading stuff like utf16 or ucs4 files will show trash too |
| 00:01.17 | jbit | id say keep iconv |
| 00:01.25 | jbit | unless youre really that short on space |
| 00:01.33 | freezi | and nls? |
| 00:01.45 | jbit | well nls itself is small, but all the locale data that goes with it is big |
| 00:01.59 | jbit | because it contains translations for all the application text |
| 00:02.09 | freezi | where does libiconv and gettext come into all this? |
| 00:03.10 | jbit | well i think the uclibc iconv stuff means you dont need libiconv |
| 00:03.57 | jbit | gettext is a method of doing localization |
| 00:04.26 | *** join/#uclibc samuraj (n=szalonuk@cvn34.internetdsl.tpnet.pl) |
| 00:07.23 | freezi | unicode solves all of this? |
| 00:07.52 | jbit | not really |
| 00:08.11 | jbit | if everything you deal with is unicode you can probably do away with iconv at least |
| 00:08.34 | jbit | but gettext/nls is for translation of text from whatever the app is writen with into another language |
| 00:09.46 | jbit | so "gettext("Hello")" might return the string "Bonjour" on a french system |
| 00:13.25 | freezi | ok. thank you, i think i have a better grasp now. it was awfully confusing before |
| 00:13.34 | jbit | its a confusing area |
| 00:13.52 | jbit | but really unless youre in a closed box embedded device, iconv is good to have |
| 00:14.09 | jbit | since somebody will try to read a big5/shift-jis/iso-8859 file and get trash |
| 00:14.34 | jbit | and really windows is still infecting the world with this stuff, i think vista finally defautls to unicode though |
| 00:14.38 | *** join/#uclibc CIA-2 (n=CIA@208.69.182.149.simpli.biz) |
| 00:14.51 | freezi | really? what did windows use before? |
| 00:15.01 | jbit | various things depending on where you are |
| 00:15.52 | jbit | shift-jis for japan, big5 for china, koi8 for russia, iso 8859 for europe |
| 00:16.22 | jbit | its a big mess ;( |
| 00:16.44 | freezi | wow ya |
| 00:19.23 | *** join/#uclibc likewhoa (n=y0@ool-45717734.dyn.optonline.net) |
| 00:21.32 | jbit | freezi: it gets even more fun if you include all the old unix standards too |
| 00:21.41 | jbit | unix systems in japan would use euc-jp |
| 00:21.50 | jbit | which is of course completly incompatible with shift-jis |
| 00:23.06 | freezi | i wish we had a global language |
| 00:23.33 | jbit | unicode helps alot though |
| 00:23.52 | jbit | most unix-ish systems are now utf8, and windows is getting there too |
| 01:05.35 | *** join/#uclibc CIA-18 (n=CIA@208.69.182.149.simpli.biz) |
| 02:09.35 | *** join/#uclibc wrobbie (n=rob@203.117.215.163) |
| 04:20.47 | *** join/#uclibc landley (n=landley@rrcs-71-42-137-189.sw.biz.rr.com) |
| 04:58.01 | *** join/#uclibc landley (n=landley@cpe-70-116-30-223.austin.res.rr.com) |
| 06:51.41 | *** join/#uclibc mlankhorst (n=m@wine/developer/mlankhorst) |
| 06:51.54 | mlankhorst | When will the next version of uClibc be released? |
| 07:03.37 | landley | There's an assumption in that statement. |
| 07:03.47 | landley | Knock off the "when" and ask it again. :P |
| 07:04.21 | landley | Keep in mind that the current nominal maintainer hasn't even updated the about section on the web page to name himself maintainer yet. |
| 07:04.30 | landley | It still says erik andersen. |
| 07:04.45 | landley | Also, which fork becomes the next release? |
| 07:05.09 | landley | The nptl fork, or the normal development fork? |
| 07:05.32 | landley | It probably won't be the blackfin one mike maintains for his day job, I don't think that's public. |
| 07:05.45 | landley | The most active one is Peter Mazinger's tree, and he got chased away from development by developers who since went dormant. |
| 07:06.00 | landley | The most widely tested one is gentoo's fork, which is a cross between 0.9.28 and the PSM tree, I think. |
| 07:06.07 | landley | Gentoo embedded's, I mean. |
| 07:06.30 | landley | Ask solar about that one... |
| 07:07.17 | jbit | i never knew uclibc was so complex! :) |
| 07:07.29 | mlankhorst | I don't think the nptl tree has support for i386 or 64 bit |
| 07:09.29 | mlankhorst | Unless they finally added that |
| 07:12.57 | mlankhorst | But last time I tried uclibc svn had pretty broken headers, perhaps it's better now. |
| 07:18.52 | mlankhorst | Personally I'm for all the work to be merged, splintered development sucks. :-/ |
| 07:20.56 | mlankhorst | Which one are you using for fwlinux landley ? |
| 07:21.34 | landley | mlankhorst: I'm using the last release, plus bugfix patches. |
| 07:21.40 | landley | So 0.9.29 + patches. |
| 07:21.51 | landley | I've pondered putting out a 0.9.29.1 on general principles. |
| 07:21.55 | landley | SOMEBODY should have done that by now... |
| 07:22.20 | landley | I'm aware that the math support in that sucks, and I should probably grab the gentoo tree if I want that improved. |
| 07:22.57 | landley | I don't particularly care about threading performance as long as it minimally works, so I'm happily using the "old threads" stuff. |
| 07:23.33 | mlankhorst | iirc nptl only works for mips as it is now. |
| 07:23.36 | landley | The nptl stuff is really about scalability beyond 1000 simultaneous threads, and if you're doing that you're probably not using uClibc anyway. |
| 07:23.43 | landley | mlankhorst: depends which tree you use. |
| 07:23.54 | landley | There's a mips nptl tree, an arm nptl tree, and an sh4 nptl tree. |
| 07:24.17 | landley | And the approach sjhill took to implementing it (for sh4, was it?) apparently bloated parts of it horribly and made it impossible to merge with the other two. |
| 07:24.28 | landley | You'd have to ask Peter Mazinger about it, though. he knows the details far more than I do. |
| 07:24.33 | landley | solar might be able to tell you, also. |
| 07:25.22 | landley | But yeah, x86 and x86-64 aren't converted to nptl, nor is there a merged tree with an agreed upon approach for such work to be done against. |
| 07:25.43 | landley | sjhill refused to merge it until he'd been paid and done his OLS presentation. |
| 07:25.48 | landley | That was... 2006? |
| 07:26.20 | landley | Yup, 2006. http://kernel.org/doc/ols/2006/ols2006v1-pages-409-420.pdf |
| 07:26.35 | landley | I think we can pretty officially declare that work dead at this point. |
| 07:26.51 | landley | Right now uClibc is essentially a stalled project. |
| 07:27.19 | landley | It doesn't have releases, it doesn't have a single unified collection point for new development work. It's forked itself a half dozen ways. |
| 07:27.22 | mlankhorst | So I should really use glibc? |
| 07:27.45 | landley | I'm sticking with 0.9.29 for now. |
| 07:28.14 | landley | I'm waiting for either a release or an acknowledgement by the community that Mike's maintainership isn't going to produce one. |
| 07:28.40 | landley | If you find specific bugs in 0.9.29, feel free to send patches my way. I may put out a 0.9.29.1 just because there should be one. |
| 07:29.12 | mlankhorst | I'm just thinking what to do for my EEE at this point. |
| 07:29.36 | mlankhorst | It has enough space to put glibc on it, and enough memory, so that isn't really an issue. |
| 07:39.14 | mlankhorst | Ah well, how bad can 0.9.29 be. |
| 07:44.13 | landley | I got 0.9.29 to work. |
| 07:44.56 | landley | I have 3 interesting bugfix patches to it, plus an optional patch to replace the config system. |
| 07:47.55 | mlankhorst | Finally a real fix for the static segfaults. |
| 07:59.55 | landley | mlankhorst: solar is prodding me to put out a 0.9.29.1 over on #edev. :) |
| 08:00.17 | mlankhorst | Go for it |
| 08:02.29 | mlankhorst | If you're quick I can even build my system against it. |
| 08:08.24 | mlankhorst | Will it just be those 4 patches? |
| 08:09.47 | landley | mlankhorst: nah, if I bother to do it I'll fix the darn sparc thing and also scan through the uClibc -devel branch to see if anything interesting comes up. |
| 08:10.03 | landley | Probably more like a dozen patches. |
| 08:11.35 | *** join/#uclibc VK4FSJL (n=vk4fsjl@203.94.56.252) |
| 08:11.42 | mlankhorst | http://cross-lfs.org/view/clfs-embedded/x86/cross-tools/uclibc-headers.html has sort of a patch |
| 08:19.43 | mlankhorst | It's sort of brute force though and I'm not sure if uclibc really symlinks the headers on install or not. |
| 08:32.21 | solar | landley: sjhill is willing to merge what he has. |
| 08:33.04 | solar | but he lacks direction. So does everybody else. All the peices are there however. Just needs some glue and a sticker to call it a shaky .30 |
| 08:33.39 | solar | .0 of anything is never stable. 30.0 |
| 08:33.49 | solar | etc.. |
| 08:42.06 | mlankhorst | Looks like uclibc needs some coordinator then. |
| 08:44.09 | solar | yes |
| 08:44.13 | solar | nite |
| 08:50.17 | landley | duct tape. I can do duct tape. |
| 08:51.51 | mlankhorst | I had to copy a glibc header to satisfy gcc v4.3.1 |
| 08:52.18 | jbit | i dislike the gcc-4.3.x reliance on target headers.... |
| 08:53.33 | mlankhorst | Me too. |
| 08:55.29 | mlankhorst | I also don't like its reliance on libgmp and co, it should at least include a copy in the tarball so creating a native compiler for a different arch won't require creating your own compiler for that arch first and then compiling gmp and co for arch.. |
| 08:56.11 | jbit | well that i don't mind so much |
| 08:56.28 | jbit | but the reliance on target headers makes it tricky to do a fresh cross compiler |
| 08:57.42 | *** join/#uclibc CIA-2 (n=CIA@208.69.182.149.simpli.biz) |
| 09:02.39 | mlankhorst | I had to wipe limits.h from uclibc to actually compile uclibc cleanly. |
| 11:59.52 | *** join/#uclibc CIA-2 (n=CIA@208.69.182.149.simpli.biz) |
| 12:52.14 | *** join/#uclibc player233687 (n=root@222.165.104.219) |
| 13:03.50 | player233687 | Re:Compilation problem w/ uClibc-snapshot & gcc-3.4.6 |
| 13:04.10 | player233687 | "undefined reference to '__fputc_unlocked'" |
| 13:04.59 | player233687 | Tried "uClibc-0.9.29-fix-fget_putc.diff" |
| 13:05.57 | player233687 | and tried disabling "Provide a macro version of getc/putc()" |
| 13:06.06 | player233687 | but error persists |
| 13:06.34 | player233687 | greatly appreciate any help |
| 13:08.11 | mlankhorst | If you can't fix this yourself, I would seriously not recommend using development releases.. |
| 13:09.46 | player233687 | sry, forgot to mention -- same error using uClibc-0.9.29 |
| 13:10.35 | player233687 | did apply the patches for 0.9.29 in "buildroot/toolchain/uClibc/" |
| 13:12.14 | player233687 | (i'm building manually instead of using buildroot b/c i want to install uClibc in a custom prefix) |
| 13:18.26 | player233687 | initial (glibc-linked) cross-compiler builds fine; the "__fputc_unlocked" error happens when building the final compiler |
| 13:19.02 | mlankhorst | Have you tried the patches from http://buildroot.uclibc.org/cgi-bin/viewcvs.cgi/trunk/buildroot/toolchain/gcc/3.4.6/ ? |
| 13:20.41 | player233687 | yea, i applied them all, basically |
| 13:21.25 | player233687 | the configuration used: http://pastebin.com/f1bbd16a |
| 13:22.16 | player233687 | (for the failing build) |
| 13:32.38 | *** join/#uclibc wrobbie (n=rob@203.117.215.163) |
| 14:35.36 | samuraj | I have created a bootable usb-stick with TinyGentoo, but during the boot process I get following errors: bad inittab entry: id:3:initdefault: and bad inittab entry: rc:bootwait:/sbin/rc boot. How to fix it? |
| 17:07.58 | *** join/#uclibc bbradley (n=bbradley@78-105-167-16.zone3.bethere.co.uk) |
| 17:41.53 | *** join/#uclibc bbradley (n=bbradley@78-105-167-16.zone3.bethere.co.uk) |
| 19:18.11 | mlankhorst | There's a bug in uClibc 0.9.29, if you include wchar.h after stdio.h it will not define mbstate_t. |
| 20:17.09 | *** join/#uclibc landley (n=landley@cpe-70-116-30-223.austin.res.rr.com) |
| 20:34.20 | *** join/#uclibc bbradley (n=bbradley@78-105-167-16.zone3.bethere.co.uk) |
| 20:47.00 | CIA-2 | 03vda * r23075 10busybox/networking/sendmail.c: sendmail: work around (bogus) gcc warning |
| 21:24.22 | *** join/#uclibc bbradley_ (n=bbradley@78-105-167-16.zone3.bethere.co.uk) |
| 23:29.33 | *** part/#uclibc mlankhorst (n=m@wine/developer/mlankhorst) |