Re: our libc included iconv library

[Takahiro Kambe <taca%back-street.net@localhost>]

Hi,

In message <4988665B.2040401%flame.org@localhost>
        on Tue, 03 Feb 2009 09:44:27 -0600,
        Michael Graff <explorer%flame.org@localhost> wrote:
> This is actually a Ruby problem, but it is not the first time I have
> encountered incompatibilities with the iconv functions included within
> NetBSD's libc and "expected" behavior from the GPL'd libiconv.
Maybe you know, this problem isn't Ruby specific but PHP.

> Case in point is this little Ruby snippit:
As for Ruby, it is recommended avoiding to use Iconv class but
String#encode function and "ruby -w" warns for using gnu libiconv
(and gnu libc) own extention.

Unfortunately, it is available Ruby 1.9 and later, but it is Ruby's
way to deal with this GNU iconv problem.  (And needs more and more
time.)

> This Iconv.iconv() call is in Ruby on Rails 2.2.2, and requires a patch
Too bad.  Many people dosen't understand what they do with iconv.

> to "fix" it.  However, all the patch does is cause it to ignore the
> exception.  This really isn't what one wants.
Yes.  But problem exists in such code fragment using iconv.

> The only other OS which seems to have this problem are older version of
> Solaris.  I would think we could do better?
As I heard before, (Open)Solaris had good implementation of iconv
(without GNU iconv/libc extention, of course) and (Open)Solaris had
the same problem.

Dose latest Solaris provide GNU libiconv only or accept GNU iconv/libc
extention?

> I can see two options here.  One is to add the // options to our libc
> iconv (probably hard) and the other is to require the gpl'd libiconv be
> linked into ruby.
As for pkgsrc ruby, a possible solution is adding option to prefer
libiconv.

Best regards.

-- 
Takahiro Kambe <taca%back-street.net@localhost>