Subject: [clisp-list] internationalization problem on clisp-2.27

From: Bernard Urban <[email-masked]>
Date: Tue Sep 4 10:40:02 2001

Last April, I was able to solve an internationalization problem 
(that is: "clisp -L french" gives me french messages) on
clisp-2.25 using the following advice:

  >>> "Sam" == Sam Steingold <<EMAIL: PROTECTED>> writes:
  >>
  >>    > * In message
  >>    > <<EMAIL: PROTECTED>>
  >>> * On the subject of "Re: [clisp-list] internationalization
  >>    > problem" * Sent on 12 Apr 2001 16:45:22 +0200 * Honorable
  >>    > bernard URBAN <<EMAIL: PROTECTED>> writes:
  >>    > > > "Sam" == Sam Steingold <<EMAIL: PROTECTED>> writes:
  >>    > Sam> Please try the following: - build libiconv (part of CLISP) -
  >>    Sam> install libiconv - reconfigure and re-build CLISP.
  >>    > 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)
                                                        ^^^^^^^^^^^^
It worked also for clisp-2.25.

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

This no longer works with clisp-2.27, with the same machines as above
and same OS as in April. (I even moved the old clisp-2.25 files to
avoid a possible interference)

Any hints ?

Regards.

-- 

Bernard Urban

---

From: Sam Steingold <[email-masked]>
Date: Tue Sep 4 16:00:02 2001

> * In message <[email-masked]>
> * On the subject of "[clisp-list] internationalization problem on clisp-2.27"
> * Sent on 04 Sep 2001 19:39:12 +0200
> * Honorable Bernard Urban <[email-masked]> writes:
>

this problem is disturbing.
yes, I do observe it from time to time, but a clean build always helps.
please do this:

$ rm -rf build
$ ./configure --build build
$ cd build
$ ./.clisp -q -norc -L french -x '(/ 0)'

-- 
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/>
The only intuitive interface is the nipple.  The rest has to be learned.

---

From: Bernard Urban <[email-masked]>
Date: Wed Sep 5 02:42:02 2001

> $ ./.clisp -q -norc -L french -x '(/ 0)'

Sorry, does not solve the problem. 
For your information, build/Makefile was created with
./makemake --with-readline --with-gettext --with-dynamic-ffi

I have tried to see if the message 
"division by 0" in the source 
is really preceded by a call to a *gettext function by
using the cpp output, the answer is yes.

So the problem seems to be related to these functions.

-- 

Bernard Urban

---

From: Sam Steingold <[email-masked]>
Date: Wed Sep 5 07:11:15 2001

> * In message <[email-masked]>
> * On the subject of "Re: [clisp-list] internationalization problem on clisp-2.27"
> * Sent on 05 Sep 2001 11:41:03 +0200

this does work for me with the current development sources.
could you please try the CVS version?
thanks!

> Sorry, does not solve the problem.
you mean, you get "message inimprimable"?!

> So the problem seems to be related to these functions.

the problem is that configure for gettext should find libiconv.

-- 
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/>
My inferiority complex is the only thing I can be proud of.

---

From: Raymond Toy <[email-masked]>
Date: Wed Sep 5 08:43:02 2001

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

    >> > $ ./.clisp -q -norc -L french -x '(/ 0)'

    Sam> this does work for me with the current development sources.
    Sam> could you please try the CVS version?

This works for me with my build of 2.27 (on Solaris).

Ray

---

From: Bernard Urban <[email-masked]>
Date: Wed Sep 5 09:23:03 2001

> could you please try the CVS version?

I just gave it a try: same problem.

> you mean, you get "message inimprimable"?!

The above is in french, I would be happy with that as a starter...
I have understand that this can happen if you give an incorrect option -E
for the console.
I have message "division by zero" instead of "Division par zéro".

> the problem is that configure for gettext should find libiconv.

It does, from the configure output:

executing build/gettext/configure ...
loading cache ../config.cache
checking for a BSD compatible install... (cached) /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets $(MAKE)... (cached) yes
checking for gcc... (cached) gcc -O
checking whether the C compiler (gcc -O   -L/home/ramses/src/Lisp/clisp-2.27/build) works... yes
checking whether the C compiler (gcc -O   -L/home/ramses/src/Lisp/clisp-2.27/build) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking how to run the C preprocessor... (cached) gcc -O -E -w
checking for ranlib... (cached) ranlib
checking for a BSD compatible install... /usr/bin/install -c
checking host system type... i686-pc-linux-gnu
checking for ranlib... (cached) ranlib
checking for POSIXized ISC... (cached) no
checking for ANSI C header files... (cached) yes
checking for working const... yes
checking for inline... (cached) inline
checking for off_t... yes
checking for size_t... yes
checking for working alloca.h... yes
checking for alloca... yes
checking for unistd.h... (cached) yes
checking for getpagesize... yes
checking for working mmap... yes
checking whether we are using the GNU C Library 2.1 or newer... (cached) yes
checking for argz.h... yes
checking for limits.h... yes
checking for locale.h... (cached) yes
checking for nl_types.h... yes
checking for malloc.h... yes
checking for stddef.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for unistd.h... (cached) yes
checking for sys/param.h... yes
checking for feof_unlocked... yes
checking for fgets_unlocked... yes
checking for getcwd... yes
checking for getegid... yes
checking for geteuid... yes
checking for getgid... yes
checking for getuid... yes
checking for mempcpy... yes
checking for munmap... (cached) yes
checking for putenv... (cached) yes
checking for setenv... yes
checking for setlocale... (cached) yes
checking for stpcpy... yes
checking for strchr... yes
checking for strcasecmp... yes
checking for strdup... yes
checking for strtoul... yes
checking for tsearch... yes
checking for __argz_count... yes
checking for __argz_stringify... yes
checking for __argz_next... yes
checking for iconv... yes
checking for iconv declaration... 
         extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft);
checking for nl_langinfo and CODESET... yes
checking for LC_MESSAGES... yes
checking whether NLS is requested... yes
checking whether included gettext is requested... yes
checking for msgfmt... msgfmt
checking for gmsgfmt... msgfmt
checking for xgettext... :
checking for bison... bison
checking version of bison... 1.28, ok
checking for catalogs to be installed...  en de fr es nl
updating cache ../config.cache
creating ./config.status
creating intl/Makefile
creating po/Makefile
creating config.h

I have also the final linking command, where I wonder why -liconv is there
(but should not cause harm):

gcc -O -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -fomit-frame-pointer -Wno-sign-compare -O2 -fexpensive-optimizations -DUNICODE -DDYNAMIC_FFI -x none spvw.o spvwtabf.o spvwtabs.o spvwtabo.o eval.o control.o encoding.o pathname.o stream.o socket.o io.o array.o hashtabl.o list.o package.o record.o sequence.o charstrg.o debug.o error.o misc.o time.o predtype.o symbol.o lisparit.o foreign.o unixaux.o ari80386.o modules.o libsigsegv.a libintl.a libiconv.a libreadline.a libavcall.a libcallback.a  -lncurses -ldl -liconv -o lisp.run

Regards.

-- 

Bernard Urban

---

From: Sam Steingold <[email-masked]>
Date: Wed Sep 5 10:28:01 2001

> * In message <[email-masked]>
> * Sent on 05 Sep 2001 18:22:37 +0200

I don't think you removed the build directory.

> I have message "division by zero" instead of "Division par zéro".

this is an entirely different problem from the one I am trying to
solve.
note that it should be "-L FRENCH" or "-L french", not "-L French".

> loading cache ../config.cache

if you are doing the fresh build,
at this time there should not be any cache.

-- 
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/>
Any connection between your reality and mine is purely coincidental.

---

From: Bernard Urban <[email-masked]>
Date: Wed Sep 5 10:52:03 2001

> I don't think you removed the build directory.

I downloaded the CVS tarball, and checked out of it the distribution, so no
build directory was present initially.

> note that it should be "-L FRENCH" or "-L french", not "-L French".

I use "-L french".

> at this time there should not be any cache.

It is the config.cache from the upper level configure. 
Isn't that normal ?

-- 

Bernard Urban

---

From: Bernard Urban <[email-masked]>
Date: Thu Sep 6 06:31:03 2001

Good news from the front ! It works now on Linux (not tried Solaris so far
to confirm Raymond Toy message).

I spotted the problem to be in gettext/intl/dcigettext.c in 
#define HAVE_LOCALE_NULL. It appears that setlocale (.., NULL) does
not work as assumed in the case of glibc2, and always returns the C
locale instead of the fr locale defined in spvw_language.d.

So undefining HAVE_LOCALE_NULL forces the code to use instead
getenv("LC_MESSAGES"), which works ok.

Also, the installation process does not need a pre-intallation of libiconv,
you proceed as the unix/INSTALL says.

One gotcha, though: you need option "-Eterminal iso8859-1" in french
language (or you have "Message inimprimable") and in spanish (or you
have message 
"Character #\u00F3 cannot be represented in the character set CHARSET:ASCII").

A long term solution to the above HAVE_LOCALE_NULL problem is probably
to test the feature through autoconf.

Regards.

-- 

Bernard Urban

---

From: Peter Wood <[email-masked]>
Date: Thu Sep 6 07:07:03 2001

On Thu, Sep 06, 2001 at 03:30:36PM +0200, Bernard Urban wrote:

...cut...

> "Character #\u00F3 cannot be represented in the character set CHARSET:ASCII").

Hi,

You can also set *terminal-encoding* to have a suitable value for
:charset, then you won't need the "-E" flag.

Peter