steve crosby wrote:
Something like:
Some applications and libraries that use locale information directly
instead of through the glibc interface incorrectly rely on the LC
variables you have set above being case-sensitive.
No, because case-sensitivity of locale names is not part of any standard.
You should run the
"locale -something" command to get the correct value to use for the LC
variables to work around issues with these broken applications and
libraries.
Unfortunately, as the latest report from Thomas indicates, this method
is also flawed. The best known suggestion so far is to look into
glibc-2.3.4/localedata/SUPPORTED (the first column) and
/usr/X11R6/lib/X11/locale/locale.alias, then try everything until both
glibc is happy (i.e. "locale charmap" prints the proper charmap) and
Xlib doesn't object.
For Thomas' case, the proper solution is to use [EMAIL PROTECTED]
I'm assuming the Xlib maintainers have been notified of the problem as well?
No, and they won't fix that. There are many other libc-like libraries on
non-Linux UNIX-like OSes that don't offer the locale mechanism exactly
in the way like glibc does.
But distro-makers do patch the /usr/X11R6/lib/X11/locale/locale.alias file.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page