[not x86 host; not glibc host; build error] bootstrapping uclibc with locale support: is it possible at all?
Rob Landley
rob at landley.net
Tue Feb 15 00:06:42 UTC 2011
On 02/14/2011 04:36 PM, Douglas Mencken wrote:
> > any attempt to build uclibc with UCLIBC_HAS_LOCALE=yes yields with:
> >
> > LN include/bits/posix_opt.h
> > HOSTCC extra/locale/gen_wc8bit -D__UCLIBC_GEN_LOCALE
> > -DCTYPE_PACKED=1 -DDO_WIDE_CHAR=1
> > extra/locale/gen_wc8bit.c: In function 'main':
> > extra/locale/gen_wc8bit.c:375:28: warning: array subscript is above
array bounds
> > extra/locale/gen_wc8bit.c:434:29: warning: array subscript is above
array bounds
> > extra/locale/gen_wc8bit.c:500:27: warning: array subscript is above
array bounds
> > GEN extra/locale/codesets.txt
> > GEN extra/locale/c8tables.h
> > sh: locale: not found
> > make: *** [extra/locale/c8tables.h] Error 1
I got locale support to sort of work in Aboriginal Linux last year, when
I was building Linux From Scratch under uClibc, although it was
converting locale data from the build host rather than containing its
own so I wound up switching it off again because it introduced extra
build dependencies. (I need to package up the minimal ones for all the
appropriate targets, it's on my todo list, but the way uClibc was trying
to do it shipped the binaries of LGPL code without shipping the source...)
I blogged about it several times:
http://landley.net/notes-2010.html#17-11-2010
http://landley.net/notes-2010.html#19-11-2010
http://landley.net/notes-2010.html#20-11-2010
Basically I switched on these symbols:
UCLIBC_HAS_LOCALE=y
UCLIBC_HAS_XLOCALE=y
UCLIBC_BUILD_MINIMAL_LOCALE=y
And then debugged a lot.
> > HOSTCC extra/locale/gen_locale -D_GNU_SOURCE
> > In file included from extra/locale/gen_locale.c:13:0:
> > extra/locale/c8tables.h:1:7: error: expected '=', ',', ';', 'asm' or
> > '__attribute__' before 'not'
> > extra/locale/gen_locale.c: In function 'do_locale_names':
> > extra/locale/gen_locale.c:227:42: error: 'lc_names' undeclared (first
> > use in this function)
> > extra/locale/gen_locale.c:227:42: note: each undeclared identifier is
> > reported only once for each function it appears in
> > extra/locale/gen_locale.c: In function 'lc_monetary_C':
> > extra/locale/gen_locale.c:1083:2: warning: #warning fix the char
> > entries for monetary... target signedness of char may be different!
> > make: *** [extra/locale/gen_locale] Error 1
> > ERROR: 'make' error. Abort.
It produces gazillions of warning as a matter of course.
> > ./extra/locale/gen_wc8bit.c does include this:
> >
> > if (!setlocale(LC_CTYPE, "en_US.UTF-8")) {
> > /* Silly foreigners disabling en_US locales */
> > fp = popen("locale -a", "r");
> >
> > I don't know anything about any "silly foreigners", but I'm sure that
> > uclibc built w/o UCLIBC_HAS_LOCALE set to "yes" has nor 'setlocale'
> > returning non-zero, nor 'locale' command.
> > So how is it possible to bootstrap locale-aware uclibc?
You need locales installed on the build machine. I.E. it pretty mch
only builds on a glibc host.
Sucks, doesn't it?
> > Also (from 'extra/locale/gen_wc8bit.c'):
> >
> > int main(int argc, char **argv)
> > {
> > FILE *fp;
> >
> > and then
> >
> > FILE *fp = popen("locale -a", "r");
> >
> > does anyway produce an error, despite any host/target (which at least
> > is easily correctable: just remove "FILE *" from "FILE *fp").
This infrastructure was never finished. It _mostly_ works, but has some
serious rough edges, is non-obvious to set up, and may have bit-rotted a
bit with newer distro locale source files.
Manuel Nova started work on a big out-of-tree fork of the code and then
started yelling at people who were checking code into the main tree and
"making more work for him" to keep his fork in sync, and managed to
actually chase away developers like Peter Mazinger who were doing such.
(Meanwhile Erik Andersen, the maintainer at the time, was off
distracted by buildroot and by his day job...)
For a while the consensus here was that doing development in a common
public repository you could actually cut releases from was a quaint
notion inhibiting the progress of uClibc. (And you wonder why it's
taken five years to ship NPTL?)
Alas, internationalization is still half-finished due to it. Manuel
hasn't posted on here in years, and nobody else has picked it back up.
Rob
More information about the uClibc
mailing list