> * In message <15557.18963.981925.177252@...>
> * On the subject of "Re: libiconv cvs has moved"
> * Sent on Tue, 23 Apr 2002 13:48:35 +0200 (CEST)
> * Honorable Bruno Haible <haible@...> writes:
>
> Sam writes:
>
> > > (Other iconv implementations are unreliable.)
> > why not let the autoconf decide on this?
>
> An autoconf test doing that would take 1 minute of configure time and
> use several megabytes of data. It's better to just hardcode the known
> good iconv()s.
in the original email you said that the only good iconv() is the one in
glibc2.2; in impnotes you list other good iconv()s.
why not use it whenever it is available since, as you said, the most
important encodings are already hardcoded?
if a user installs libiconv under /usr/local/ on, say, solaris (which
has /usr/include/iconv.h), how can we make sure we include the right
iconv.h?
What you are proposing is, essentially, making HAVE_ICONV == GNU_LIBICONV
right?
another thing, libcharset is in libiconv but not in glibc.
do I need to integrate locale_charset() in encoding.d?
--
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
Read, think and remember! <http://www.iris.org.il&gt; <http://www.memri.org/&gt;
<http://www.palestine-central.com/&gt; <http://www.mideasttruth.com/&gt;
Murphy's Law was probably named after the wrong guy.

Sam writes:
> do I understand correctly that the CLISP cannot do UNICODE without a
> usable iconv?
Wrong. UNICODE will work on these platforms as well - because I have
hardcoded the most important encodings in encoding.d. The only thing
that will be different is that the number of available encodings will
be smaller (see encoding.d:encoding_from_name()).
> > (Other iconv implementations are unreliable.)
> why not let the autoconf decide on this?
An autoconf test doing that would take 1 minute of configure time and
use several megabytes of data. It's better to just hardcode the known
good iconv()s.
> how can one check whether iconv() understands UNICODE?
$ echo | iconv -f ASCII -t UNICODE
We already have a good determination of CLISP_INTERNAL_CHARSET in
stream.d.
Bruno

Patches item #547491, was opened at 2002-04-23 12:32
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=301355&aid=547491&group_id=1355
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jörg Höhle (hoehle)
Assigned to: Nobody/Anonymous (nobody)
Summary: C-VAR-ADDRESS and OFFSET foreign-places
Initial Comment:
Please apply the following patch to the CLISP FFI
NB: to actually use c-var-address you'll have to wait
for the patch implementing the FOREIGN-ADDRESS function
(use my ffilext.lisp in interim).
CL-PDF is going to make use of these new
interface functions in its zlib-clisp.lisp
Regards,
Jörg Höhle
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=301355&aid=547491&group_id=1355

Dear Bruno,
> * In message <15555.63221.175415.446738@...>
> * On the subject of "libiconv cvs has moved"
> * Sent on Mon, 22 Apr 2002 13:41:41 +0200 (CEST)
> * Honorable Bruno Haible <haible@...> writes:
>
> I have moved the libiconv directory out of clisp cvs. It is now at
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/libiconv/
okay.
> and update the surrounding infrastructure to use iconv() if available
> and only if found in glibc or GNU libiconv.
do I understand correctly that the CLISP cannot do UNICODE without a
usable iconv?
on freebsd, `man -k iconv` returns nothing; does it mean that we lose
UNICODE on that platform right away?
> (Other iconv implementations are unreliable.)
why not let the autoconf decide on this?
how can one check whether iconv() understands UNICODE?
> The points needing care are:
> - top level configure
> - makemake.in
> - definition of GNU_LIBICONV in lispbibl.d.
Actually, I thought you were going to do it. :-(
--
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
Read, think and remember! <http://www.iris.org.il&gt; <http://www.memri.org/&gt;
<http://www.palestine-central.com/&gt; <http://www.mideasttruth.com/&gt;
The only thing worse than X Windows: (X Windows) - X

Hi Sam,
I have moved the libiconv directory out of clisp cvs. It is now at
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/libiconv/
This being done the way is free for you to remove it from the clisp
cvs:
cd clisp
files=`find libiconv -type f | grep -v /CVS/`
rm -f $files
cvs remove $files
cvs commit $files
and update the surrounding infrastructure to use iconv() if
available and only if found in glibc or GNU libiconv. (Other iconv
implementations are unreliable.) The points needing care are:
- top level configure
- makemake.in
- definition of GNU_LIBICONV in lispbibl.d.
Bruno