Locales strike back

Rob Landley rob at landley.net
Mon Jun 1 05:47:02 UTC 2015


On Sun, May 31, 2015 at 4:13 AM, Jaromír Cápík <tavvva at 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


More information about the uClibc mailing list