tlug: kterm error message

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "John" == John G Baniewicz <john.baniewicz@example.com> writes:

    John> After upgrading from RH4.2 to 5.0 and now 5.1, I'm once
    John> again trying to get Japanese support working on my system.
    John> Under RH4.2, things worked fairly smoothly as far as the
    John> input, display, and printing of Japanese were concerned.  My
    John> latest attempt to get Japanese going on RH5.1 does not seem
    John> to have gotten off to a good start.

You've been hosed by the decision of the XFree86 people to not enable
support for X's locale kludge in glibc builds because glibc supports
POSIX locales properly.  Unfortunately, Japan is one of the locales
that isn't ready for prime time yet.

IMHO glibc locale support isn't really there either, the documentation 
of how to build locales is sparse (as of a few months ago; this may
have changed recently but surely hasn't really shaken down yet).

    John> You should be aware that a kterm does indeed appear, and it
    John> can display Japanese.  (I did set up "LANG=ja_EUC" in my
    John> .bash_profile.)  Nevertheless, I am a little concerned that
    John> something isn't configured properly.  (The version of glibc
    John> that I have is glibc-2.0.7-19.)  Consequently, I have not
    John> attempted to get either canna or wnn up and running.  (I
    John> figure if there is a problem, now's a good time to nip it in
    John> the bud.)

Probably everything will in fact work properly as long as LANG is
either C or ja*.  At least if the binaries are old enough: Japanese
hackers have spent enormous amounts of effort kludging around the lack
of locale support (instead of assembling the necessary locale data),
and lots of Japanese programs (including older versions of kinput2 and
kterm) simply default to the right locale and do the work of the
locale functions internally.

    John> kterm: error in loading shared libraries
    John> : undefined symbol: _Xsetlocale

Translation:  "kterm: too new".

    John> The bottom line is I'm stuck.  I'm more than willing to try
    John> compiling XFree86 from source, if I only had a better idea
    John> of what i must do to get the job done.

Brave man.  I don't know how badly hacked the i386 sources are, but
compiling RedHat's source RPM for X11R6.3 on Sparc is one of my top
three reasons for hating Red Hat.  I don't recommend messing with Red
Hat sources, especially the 100MB X11 distribution, as your first
build from source.  _Especially_ not if you want to fix something
related to Japanese and locales: much of the ugliest code that I've
seen in X is in the Wnn4 configure stuff---it would be _very_ easy to
break it by changing something in the Xlib configuration.

A much better place to start big is with the Linux kernel or an Emacs
variant.  I don't really recommend gcc or egcs; they are if anything
even more fragile and OS/hardware dependent than X11 is, although
they're generally pretty stable and straightforward these days.

    John> I'd be very grateful if anyone could get back to me on how I
    John> can get things properly up and running.

I haven't any complaints[1] with TurboLinux's Japanese support.  I would
strongly recommend dishing out the yen for the 2.0J-Pro CD as the
fastest route to a reasonably stable system.  This should get you
compatibility with most RedHat RPMs that don't exist in TL yet, and
you can ask Scott for help if they don't work for you; he seems to be
more than willing to add packages on a single user's request,
especially if it's just a matter of small tweaks in an existing source 
RPM.

If that's not appealing but you do have the bandwidth, download
Scott's X11 .rpms and install them, and learn to use rpm -q to find
out what the dependencies are and replace required packages with TL
versions until the system stabilizes.

Footnotes: 
[1]  Well, I wouldn't if Scott hadn't specifically instructed me to
     beat on the betas until I found something to complain about.  :-)

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences        Tel/fax: +1 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for?  "Free software rules."
---------------------------------------------------------------
Next Nomikai: 20 November, 19:30 Tengu TokyoEkiMae 03-3275-3691
Next Meeting: 12 December, 12:30 Tokyo Station Yaesu central gate
---------------------------------------------------------------
Sponsor: PHT, makers of TurboLinux http://www.pht.co.jp