----- Forwarded message from Owen Taylor <otaylor@redhat.com> -----
To: Michael Sobolev <mss@despair.transas.com>
Subject: Re: xlib6 problem in Debian
Cc: Branden Robinson <branden@purdue.edu>
From: Owen Taylor <otaylor@redhat.com>
Date: 30 Aug 1998 18:29:56 -0400
[
I'm CC'ing Branden Robinson on this because it seems my
earlier bug report was somewhat misleading. It might
actually be worth forwarding this to an appropriate
mailing list to give other people a chance to comment
on the situation.
]
Michael Sobolev <mss@despair.transas.com> writes:
> Hello.
>
> As far as I see in the changelog file, it was you who suggested to use
> -DX_LOCALE while compiling xlib library.
>
> Could you please provide more background?
The basic background is in my bug report:
http://www.debian.org/Bugs/db/25/25076.html
However, looking back on it, it seems my understanding of
the problem was not complete.
>From the Xlib sources, it appears that if the libraries were compiled
with -DX_LOCALE, then the Xlib will never try to get the locale from
libc. The effect of this is for programs that were not compiled with
-DX_LOCALE, locale switching will not work correctly.
(If a program is compiled with -DX_LOCALE and includes
<Xlocale.h>, setlocale() will be #define'd to _Xsetlocale())
So the tradeoff is:
If -DX_LOCALE is used:
* All X programs that call setlocale() must be recompiled with
-DX_LOCALE and must include <Xlocale.h>, or X's locale
code will not work properly. (For instance, compose handling
will not work)
(If GTK+ is compiled such that it uses -DX_LOCALE, then
programs that use GTK+ would not need recompilation; but
programs using other toolkits probably would need
individual attention)
* If these same programs try to use locale-handling from libc,
it will not work correctly. (For instance, functions like
isalpha() will always use the C locale). This happens
because libc's setlocale() will not be called.
If -DX_LOCALE is not used:
* The Debian X libraries will not be useful for the CJK
(China-Japan-Korea) locales, since glibc-2.0 does not
support these locales.
Although neither alternative is attractive, it seems the
second one is preferable in that it gives correct handling
for one-byte locales and does not require updating a large
number of the X based packages. It also is more forward
looking in that it will eventually work with the CJK
locales when glibc does have such support. (I know that
is planned, though I'm not sure if it is in 2.1)
So, with that in mind, I would recommend that the change
be reversed.
A third possibility would be to patch Xlib to improve the locale
handling under glibc. It should not be hard to make up a patch that:
* if _Xsetlocale() has not been called, queries libc for the locale
and uses that.
* When _Xsetlocale() is called, calls the libc setlocale()
in addition to storing the settings internally.
This should allow programs compiled without -DX_LOCALE to operate as
well as they did when the server was not compiled with -DX_LOCALE, and
allow programs compiled with -DX_LOCALE to operate correctly in both
CJK and one-byte locales.
If this is considered desirable, I could make up such a patch.
> The reason I am asking is that
> I started to have problem when this was done. My investigatino shows that
> in case of -DX_LOCALE for my application (actually, not mine, it was
> WindowMaker) with appropirately compiled libraries, I could not get Russian
> menus to appear.
> What I found was that the functino XCreateFontSet loads
> only one font (-iso8859-1) instead of two (-koi8-r and -iso8859-1). So it
> looks for me that X locale stuff does not work. Am I missing something?
I don't think so. Your symptoms sounds consistant with my current
understanding of the sitatuation.
Regards,
Owen
----- End forwarded message -----
--
G. Branden Robinson | Kissing girls is a goodness. It is a
Purdue University | growing closer. It beats the hell out
branden@purdue.edu | of card games.
http://www.ecn.purdue.edu/~branden/ | -- Robert Heinlein
Attachment:
pgp2Io88WqeUV.pgp
Description: PGP signature