[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Are we going with X_LOCALE or not?


On Fri, Sep 11, 1998 at 11:35:07AM -0400, Branden Robinson wrote:

> I'm reversing this change for the next release of xlib6g, and will continue
> to build xlib6g without X_LOCALE for the forseeable future.

Branden, do you have an ETA for that version? (I'll have to rebuild wmaker
when that happens, and I just want to keep an eye on Incoming)

> On top of everything else, WindowMaker appears to break if X_LOCALE is
> defined.

No, it doesn't break. I just didn't realize what happened; It was just an
issue of supplying the correct dependency information (xlib6g >= 3.3.2.?).
There's a FAQ.I18N in WindowMaker, it reads:

        - if your OS doesn't support any locale or if your OS doesn't 
          support a locale for your language, you can use X Window System's
          locale emulation feature instead of OS's locale. To use this
          feature, add this option to the configure, "--with-x-locale".
          [...] if your OS is Linux or NetBSD or .. , it's possible
          your locale is not supported so far. then use "--with-x-locale".

          Note: to use X's locale emulation, your Xlib has to be
                compiled so that the locale emulation is enabled.
                Linux RedHat5.0's default Xlib is not compiled 
                like that. (RH4.x are ok).

And configure.in says:

dnl Decide which locale function to use, setlocale() or _Xsetlocale()
dnl by MANOME Tomonori 
dnl ===========================================

If I'm reading this right, at the time Debian's X didn't have -DX_LOCALE,
this just failed and _Xsetlocale wasn't used. The release that used
-DX_LOCALE suddenly made this test successful, and everything was compiled
with -DX_LOCALE, but there's *nothing* in WindowMaker that uses that define,
main.c reads:

./src/main.c:/* Xlocale.h and locale.h are the same if X_LOCALE is undefind in wconfig.h,

And Xlocale.h says:

#define setlocale _Xsetlocale

that is, applications built with -DX_LOCALE (on *their* compilation, not
X's), get X's emulation. The rest doesn't. The problem seems to be there are
applications (like WindowMaker) that force X_LOCALE if X's locale emulation
is found. If Branden removes -DX_LOCALE, wmaker will break again (I just
have to rebuild it). Multibyte characters under X is a different issue, I
think (the _MB_ functions vs the regular ones)

> 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.

On the issue of inter-distribution compatibility, Debian's wmaker won't run
on RH if RH doesn't use -DX_LOCALE and viceversa. It *will* run if Debian
doesn't use -DX_LOCALE and RH does.


Reply to: