Subject: Re: [clisp-list] internationalization problem

From: bernard URBAN <[email-masked]>
Date: 12 Apr 2001 16:45:22 +0200

>>>>> "Sam" == Sam Steingold <[email-masked]> writes:

    >> * In message <[email-masked]> * On the subject of
    >> "[clisp-list] internationalization problem" * Sent on Wed, 11
    >> Apr 2001 19:05:20 +0200 * Honorable bernard URBAN
    >> <[email-masked]> writes:
    >> 
    >> $ clisp -q -norc -L francais [1]> (/ 0) *** - Message
    >> inimprimable *** - invalid byte #xF3 in CHARSET:UTF-8
    >> conversion, not a Unicode-16

    Sam> Please try the following: - build libiconv (part of CLISP) -
    Sam> install libiconv - reconfigure and re-build CLISP.

Done, but problem remains the same.
Outside Solaris, I also have the same problem on a Linux (Debian) box.
On Solaris, I tried the clisp-2.25.1 binaries, same problem.

More details on Solaris: 
libiconv.a and libintl.a are build in base and full directories.
There are Sun /usr/lib/libintl.so and /usr/include/iconv.h on
my Solaris box. clisp insists on building libiconv.a, even if it
detects this system iconv. 

It would be helpful to start from a platform where these things work.
I guess that Bruno Haible uses the german interface and it works for
him, so what is he using for his computer ?
Last time I had a working internationalized clisp was on HP-UX
(version from 1999).

This bug is really annoying to investigate, as by definition, most
messages printing in the clisp debugger are subject to the same error, 
so you have an error in the debugger itself,
and so all things end messed up. At least, I have no infinite loop...

Perhaps printing in the debugger should be (optionally) formatted
without internationalization ?

    >> And about internationalization, how do the clisp developpers
    >> edit their files with all these Unicode codings ?  Basic emacs
    >> does not seem to understand Unicode.

    Sam> Emacs 21 does - that's what I use (I have access to the CVS).

Ok, you are ahead of the crowd... I will try some japanese (!) MULE
extension which is rumored to do Unicode.

Thank you for trying to help on this topic.

Regards.

-- 

Bernard Urban

---

From: Sam Steingold <[email-masked]>
Date: 12 Apr 2001 11:49:58 -0400

> * In message <[email-masked]>
> * On the subject of "Re: [clisp-list] internationalization problem"
> * Sent on 12 Apr 2001 16:45:22 +0200
> * Honorable bernard URBAN <[email-masked]> writes:
>

Here is what you should have done:

  1) make distclean in the CLISP directory.
  2) cd libiconv
     ./configure --disable-shared
     make
     make install
     make distclean
  3) set the environment variables
       CPPFLAGS=-I/..../include    so that it will find <iconv.h>
       LDFLAGS=-L/..../lib         so that it will find libiconv.a
     and export them
     Here "...." is the path where the previous "make install" installed
     the files iconv.h and libiconv.a
  4) back to CLISP main directory
     ./configure
     and continue as usual

Does this help?

> my Solaris box. CLISP insists on building libiconv.a, even if it

CLISP uses some GNU libiconv features not present in the Solaris
libiconv. 

> him, so what is he using for his computer ?

the above instructions are directly from him.

apparently, libiconv has to be installed on the system when CLISP is
being configured.

Good luck - and thanks for using CLISP!

-- 
Sam Steingold (http://www.podval.org/~sds)
Support Israel's right to defend herself! <http://www.i-charity.com/go/israel>
Read what the Arab leaders say to their people on <http://www.memri.org/>
All generalizations are wrong.  Including this.

---

From: bernard URBAN <[email-masked]>
Date: 13 Apr 2001 15:16:32 +0200

>> * In message
    >> <[email-masked]>
    >> * On the subject of "Re: [clisp-list] internationalization
    >> problem" * Sent on 12 Apr 2001 16:45:22 +0200 * Honorable
    >> bernard URBAN <[email-masked]> writes:
    >> 
    >>  Done, but problem remains the same.

    Sam> Here is what you should have done:

    Sam>   1) make distclean in the CLISP directory.  2) cd libiconv
    Sam> ./configure --disable-shared make make install make distclean
    Sam> 3) set the environment variables CPPFLAGS=-I/..../include so
    Sam> that it will find <iconv.h> LDFLAGS=-L/..../lib so that it
    Sam> will find libiconv.a and export them Here "...." is the path
    Sam> where the previous "make install" installed the files iconv.h
    Sam> and libiconv.a 4) back to CLISP main directory ./configure
    Sam> and continue as usual

    Sam> Does this help?

Yes, it works !!! (tested on Solaris, I will try on Linux Debian later)
In all cases, clisp builds the libiconv.a in its distribution, so it
does not make sense to TEST for an external iconv in the configure process.

    >> More details on Solaris: libiconv.a and libintl.a are build in
    >> base and full directories.  There are Sun /usr/lib/libintl.so
    >> and /usr/include/iconv.h on my Solaris box. CLISP insists on
    >> building libiconv.a, even if it detects this system iconv.

    Sam> CLISP uses some GNU libiconv features not present in the
    Sam> Solaris libiconv.

    >> It would be helpful to start from a platform where these things
    >> work.  I guess that Bruno Haible uses the german interface and
    >> it works for him, so what is he using for his computer ?

    Sam> the above instructions are directly from him.

    Sam> apparently, libiconv has to be installed on the system when
    Sam> CLISP is being configured.

Perhaps to be put in the README:
the emacs package Mule-UCS-0.83 extends emacs-20 to read Unicode files. 

And to finish some buglet when compiling clisp with the gcc version:
$ gcc -v
Reading specs from /export/home/urban/lib/gcc-lib/sparc-sun-solaris2.7/2.95.3/specs
gcc version 2.95.3 20010315 (release)
$

which does not understand '-Wreturn-type' compilation option.

Regards.

-- 

Bernard Urban