Subject: Re: How to enable USE_GNU_ICONV for glib2?
To: None <>
From: Julio M. Merino Vidal <>
List: tech-pkg
Date: 01/06/2006 20:32:56
On 1/6/06, Bernd Ernesti <> wrote:
> On Fri, Jan 06, 2006 at 06:55:09PM +0100, Julio M. Merino Vidal wrote:

> > It seems dangerous to me to make this option package-specific.  Having
> > a mixture of packages (libraries) built with different implementations =
of iconv
> > will surely cause problems if both libraries are loaded at the same tim=
e by a
> > concrete program.  I hit this problem -- random crashes -- with differe=
nt SSL
> > implementations.  (And this is one of the reasons I added the plural ha=
> > hack in gettext-lib.)
> But what should we do with glib2, which seems to not enable all features =
> the native iconv?

Hmm... I'm really not fond on the idea of having a slightly-broken glib2
package, because this might cause all sort of problems in "unrelated"
software.  In this case, irssi is clever enough to detect the misfeature,
but other programs could not be.

But I'm also afraid of making glib2 (and glib2 alone) depend on gnu iconv i=
all cases (I know, not your proposed solution).  Consider a program that us=
such a glib2 and a foo library -- foo does not depend on glib2 and uses the
native iconv.  This program will very likely fail at runtime.

AIUI, USE_GNU_ICONV is something that should be set on a per-system
basis, not on a single package -- similarly to all to the

> > Maybe we'd have a glib2-gnu package that relies on gnu iconv and gnu
> > gettext, which might be parallel installable with glib2 and could be us=
ed by,
> > e.g., irssi?
> The best would if the citrus iconv would support the needed things for ir=

Indeed; but even if this happens, we'll be left with supported NetBSD
releases that will include older versions...

Note that I'm not trying to discourage you from doing the change.  I'm just
trying to analyze all possible problems that may arise and how they can be


Julio M. Merino Vidal <>
The Julipedia -
The NetBSD Project -