On Fri, Sep 11, 1998 at 12:54:52PM +0900, Kaz Sasayama wrote: > I was surprised when a new 3.3.2.3 version of X packages > were released, because it defined X_LOCALE even with the > libc6 version. So I ask: > > Are we going with X_LOCALE for any later version of libc6, > or just for a version that does not support full i18n? I'm reversing this change for the next release of xlib6g, and will continue to build xlib6g without X_LOCALE for the forseeable future. At the time I added the flag, I mistakenly thought it could do no harm, and would instead simply permit those using East Asian locales to use X more painlessly. But as you've observed, there is a binary compatibility issue. Furthermore, I've heard complaints from some Russians, so apparently glibc's locale handling is better for them than X's. On top of everything else, WindowMaker appears to break if X_LOCALE is defined. > What is important, IMHO, is to choose one and keep it > unchanged until another big change happens either in libc or > in X. Do you have any plan? I guess the best thing to do is hope that glibc 2.1 supports East Asian locales. In the meantime, I'm considering suggesting that those who need East Asian locales turn to the Debian-JP project, who already do their own builds of X to support such things. Owen Taylor of Red Hat, who originally made the suggestion to define X_LOCALE even in the libc6 build, said he might be able to hack up the Xlib source to rely on C locales where available, and fall back on X ones when they weren't. I haven't considered all the ramifications of such a hack. Sorry about the confusion. -- G. Branden Robinson | Reality is what refuses to go away when Purdue University | I stop believing in it. branden@purdue.edu | -- Philip K. Dick http://www.ecn.purdue.edu/~branden/ |
Attachment:
pgpHo4iHJwq7_.pgp
Description: PGP signature