Locales strike back

Jaromír Cápík tavvva at seznam.cz
Mon Jun 1 10:12:24 UTC 2015


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



What license violation? The glibc library is released under the GPL

license and therefore you can freely redistribute and modify

sources and even binary data.

 

"and I _really_ didn't want to throw a glibc source tarball in the
uclbic download directory."



I don't think you need to.


 



"> 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.)"



I don't see any.







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



I really don't get what copyright infringement you're writing about.






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



Well ... I built libiconv & gettext and that allows me to continue

at least. I cannot change the C library like shoes :]

uClibc is proven to be quick and reliable.





 

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



Hmm ... why the 'complicated' archive name then?

It looks more like created for tests, but never uploaded

or uploaded and then deleted as broken or because

someone thought it violates licenses? 





J.



More information about the uClibc mailing list