[uClibc]locale support in uClibc 0.9.12
Manuel Novoa III
mjn3 at codepoet.org
Tue Jul 16 00:51:44 UTC 2002
Hello,
On Sun, Jul 14, 2002 at 09:38:01PM -0700, David Meggy wrote:
> Hi, I'm having troubles getting the locale support to work in the latest
> uClibc version.
Not surprising as it is mainly a proof-of-concept at the moment. Even
ignoring the fact that collation support is missing, it is not in a
finished form. My main goal was to get an idea of how much space was
needed to support the standard (ANSI/SUSv3) locale functionality.
Secondarily, I needed enough locale support to start implementation of
the wchar.h functions. The eventual goal is to generate a shared
mmap-able locale data file to better support no-MMU systems.
> The first problem I solved myself and the patch is
> below. The patch is needed for cross compiling.
I'm afraid it isn't that easy. If it were, there wouldn't be the error
message. ;-)
There are potential issues with padding and alignment of data in the
structure. This is one of the problems I need to address. While your
patch may work for you, it may not either. It may be necessary for you
to build gen_mmap for your target arch, run it there, and copy the
generated file back to your development system to continue the build.
> The second problem is
> with extra/locale/gen_wc8bit.c. The following is a snippet from the
> main function. This fails on my system.
>
>
> if (!setlocale(LC_CTYPE, "en_US.UTF-8")) {
> printf("setlocale(LC_CTYPE,\"en_US.UTF-8\") failed!\n");
> return EXIT_FAILURE;
>
>
> If I comment it out, I only run into more problems later. How can I get
> around this problem?
The easiest way is to just generate the en_US.UTF-8 locale for glibc.
However, just about any other UTF-8 locale for glibc (>= 2.2) will suffice.
This is only used for generation of the isw*() and tow*() data for the
wctype.h functions. Note though that the turkish locale has a couple of
different towupper/towlower mappings than all other glibc locales.
Manuel
More information about the uClibc
mailing list