On Sun, May 31, 2015 at 4:13 AM, Jaromír Cápík <tav...@seznam.cz> wrote: > > "> Does anybody have working pre-generated >> locales for uClibc 0.9.30? >> I tried to generate them by myself on a glibc >> based system, but they are not generated >> properly and cause build errors with excess >> elements in array, etc. >> >> Please, tell me. > > This might be related to my post from March titled "Broken assumptions > in gen_wctype"."" > Rich" > > Hello Rich. > > I've read many threads about uClibc and locales, but > none of them seems to bring a solution.
The guy who implemented locale support for uClibc, Manuel Nova, never quite finished it, and left the code with a config symbol "manuel's warnings". He wandered away from uClibc development almost ten years ago, and nobody really inherited his work. Sounds like it's bit-rotted. I took a stab at it a few years back, but distributing a binary tarball of data sourced from glibc seemed like a license violation, and I _really_ didn't want to throw a glibc source tarball in the uclbic download directory. > 0.9.28 worked well with the following pre-generated locales > > http://www.uclibc.org/downloads/uClibc-locale-030818.tgz See "probable license violation", above. (Maybe locale data isn't copyrightable? Scenes a' faire? No idea, not personally going there. You don't get these problems with musl.) > 0.9.30 doesn't crash and is re-buildable from the upstream > provided system-image-m68k.tar.bz2, but it doesn't accept > > data from the above archive and when I enable download > > of pre-generated locales, it tries to pull a non-existent > uClibc-locale-20081111-32-eb.tgz archive. Yeah, a patch was checked into uclibc but the corresponding file was never updated. The commit says: http://git.busybox.net/uClibc/commit/?id=ab600d2ad032 "We will retroactively fill them in, eventually" but Bernhard was underestimating how dead the project was. Keep in mind this happened _after_ uClibc developement cratered back in 2007: http://lists.uclibc.org/pipermail/uclibc/2007-September/039215.html Bernhard came in and tried to fix stuff. I myself tried to fix the locale thing myself but hit the above license issues, so didn't upload it: http://lists.busybox.net/pipermail/uclibc/2009-January/041758.html There's a problem that uclibc was never quite an independent project, it copied glibc headers, copied glibc locale data, snapshotted glibc's thread implementation... If you don't care about licenses at all and don't thing the FSF will ever sue you, then it's fine. If you _do_ treat the FSF like a wounded rabid weasel, and don't want to get any of it on you, this poses a problem. Basically you're underestimating how many years this project has been struggling for. The above message about development stalling was from 2007, and the project never really recovered from that stall. The third anniversary of the last-ever release was two weeks ago, and that's over a year after bulidroot threatened to walk. Meanwhile, musl's 1.0 release was a little over a year ago, it's going strong, and a number of distros have adopted it. If you wonder why I haven't been trying to fix stuff here like I used to, I've been following the project since http://landley.net/notes-2012.html#29-09-2012 or so... > I'd like to find some workaround or enable at least basic > support so that I could build packages with locale support > till a solution is found. Adding m68k support to musl is probably easier than fixing locale support in uClibc. No really. > Anybody has got a copy of the above archive? I don't think it was ever uploaded. I'm not sure it was ever actually made. Rob _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc