One problem forgotten about LOCALE
if you are trying to build the locale stuff (not using the pregenerated
data), then it has problems after building gen_wctype and running
./gen_wctype en_US. If I run make in extra/locale from the command prompt
it works, but if I try to build it through rpm, it segfaults (the segfault
is caught by grsec as RLIMIT_STACK resource overstep) after the message
"optimizing is* table..". I think that it is due to the background
processing, it could also be a problem for gentoo.
Some other thoughts about locale:
If locale is not builtin, uClibc provides support for an UTF-8
mini-locale, as I remember (if WCHAR support is enabled)
If locale is builtin, then, as I remember, the language specific messages
are not supported. It rumored, that the support will be ready for
dec-jan, who knows.
The libraries get 135kB bigger if full locale is added. We gain bits/bytes
from the binaries only if disable-nls is consistently used. There are
some packages that won't even build w/o locale support and if they do not
find it they will use the integrated one, which means static libintl.a, so
they will get bigger then built against a uClibc provided shared libintl.
Somehow it should be evaluated (maybe based on a glibc version), what
costs less/more bytes:
a. to build the special cases that need locale against a static library
and build the rest without locale support
b. build all the stuff against the shared libintl from uClibc (although
there are some packages, that require the full gettext release to build)
I tend to believe on the long run the locale support should be in.
One big advantage of having locale support in, is that we can build many
packages w/o problems, if we do not have locale in, then we need full
gettext, but then the question arises, should be deliver libintl.so and
depend also on the gettext version (0.12.1 was unusable w/ uClibc -
maybe only for me ;-( ), or provide libintl.a and produce bigger binaries.
All the problems mentioned in this and earlier mail were already reported
to the uclibc developers, but they are planning to make incompat changes,
so they fix minimally problems in 0.9.23 and get 0.9.24 out, after that
we have to start from the beginning, so do not build too many packages ;-)
Peter S. Mazinger <ps.m@...> ID: 0xA5F059F2 NIC: IXUYHSKQLI
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
Miert fizetsz az internetert? Korlatlan, ingyenes internet hozzaferes a FreeStarttol.
Probald ki most! http://www.freestart.hu
firstname.lastname@example.org mailing list