Re: Patch for iconv-impaired systems

[Sebastian Wilhelmi <wilhelmi ira uka de>]

Hi Owen,

> > recently I tried to compile GLib on aome platform (I forgot which) without
> > iconv. I will commit the following patch, if noone objects:
> >
> > Now g_convert_* just throws an error, if called on a platfrom without iconv.
> > That makes GLib at least compile. It might however be a good idea to at least
> > implement some basic and often wanted conversions explicity on such platforms
> > later.
> >
> > The guard for including iconv.h is HAVE_ICONV and not HAVE_ICONV_H, because I
> > hope, that UNIX has learned its leassons and now standardize the header names
> > as well, i.e. "iconv exists iff iconv.h exists and has the prototype".
> 
> My opinion is that GLib apps are allowed to depend on the existance
> of an iconv() (or perhaps of a g_iconv()), and allowed to assume
> g_convert() will not g_error().
> 
> Just as a an application should be able to depend on the PNG loader
> for gdk-pixbuf being there, they should be able to depend on
> being able to get a converter from GB2312 to ISO-8859-2.
> (But should check the result of g_convert anyways)
> 
> However, just because a generic application can assume the
> presence of a broad set of converters in Glib, does not mean
> a specific application needs them. This is especially true
> in the "embedded" space, where the set of applications is
> fixed, and input text and available fonts can be assumed
> to be constrained in encoding. And since conversion tables
> are a big expense for disk and possibly memory space, I think
> it would be good to eventually support compiling GLib without
> a full iconv, though with the broadly printed caveat :
> 
>  "THIS COPY OF GLIB IS NOT SUITABLE FOR GENERAL USE"
> 
> So, for right now, the right thing to move the configure
> checks for iconv from Pango to GLib; they check in the
> C library, then check for Bruno Haible's libiconv.

Ok, the attached patch should do that, what about that?

> In the future, a slightly more ambitious plan is that
> if the user explicitely compilers GLib with --without-iconv,
> to fall back to a simple internal implementation, only
> compiled in in that case that just does conversions between
> 
>  UTF-8, UTF-16 (BE/LE), UTF-32 (BE/LE?), ISO-8859-1

UTF32? Do you mean UCS4?

> And does them in the smallest possible amount of code.
> (E.g., to convert from UTF-16BE to ISO-8859-1, converts
> 
>  UTF16-BE =>  UTF-16 (native, by byteswapping) => UTF-32 (native) => ISO-8859-1
>
> Even that list is rather bigger than I like, but I think
> it can be done on top of the supplied conversions in
> GLib in ~200 lines of code, with no additional tables.
> 
> I do not want to see the inclusion of anything more than that
> in GLib - it would be a bad idea to have to maintain our own
> code conversion tables of any sort; useless duplication
> of effort. And the only reason I suggest a fallback tiny
> iconv is to save code/data-size for applications where that
> is crucial.

Yes. True.
 
> But the general principle is that GLib is (partially) a portability
> layer, so the facilities available in GLib should not depend on
> platform.

Ok, you're right. But what conversions are actually guaranteed to exist on
every platform? Anyway, shall I commit the patch?

Bye,
Sebastian
-- 
Sebastian Wilhelmi
mailto:wilhelmi ira uka de
http://goethe.ira.uka.de/~wilhelmi

Index: configure.in
===================================================================
RCS file: /cvs/gnome/glib/configure.in,v
retrieving revision 1.156
diff -u -b -B -r1.156 configure.in
--- configure.in	2000/10/30 21:55:21	1.156
+++ configure.in	2000/11/08 15:20:26
@@ -353,6 +353,14 @@
 # Check for some functions
 AC_CHECK_FUNCS(lstat strerror strsignal memmove mkstemp vsnprintf strcasecmp strncasecmp poll getcwd)
 
+# Check for iconv in libc or libiconv.
+AC_CHECK_FUNC(iconv_open,,
+	AC_CHECK_LIB(iconv, iconv_open, G_LIBS="$G_LIBS -liconv",
+		AC_MSG_ERROR(libiconv has to be installed. The latest version 
+		can be fetched from ftp://ftp.ilog.fr/pub/Users/haible/gnu/)))
+LIBS="$LIBS $G_LIBS"
+AC_SUBST(G_LIBS)
+
 # Check if bcopy can be used for overlapping copies, if memmove isn't found.
 # The check is borrowed from the PERL Configure script.
 if test "$ac_cv_func_memmove" != "yes"; then
Index: glib-2.0.pc.in
===================================================================
RCS file: /cvs/gnome/glib/glib-2.0.pc.in,v
retrieving revision 1.4
diff -u -b -B -r1.4 glib-2.0.pc.in
--- glib-2.0.pc.in	2000/09/30 02:14:03	1.4
+++ glib-2.0.pc.in	2000/11/08 15:20:26
@@ -6,5 +6,5 @@
 Name: GLib
 Description: C Utility Library
 Version: @VERSION@
-Libs: -L${libdir} -lglib-1.3
+Libs: -L${libdir} -lglib-1.3 @G_LIBS@
 Cflags: -I${includedir}/glib-2.0 -I${libdir}/glib-2.0/include 
Index: glib-config-2.0.in
===================================================================
RCS file: /cvs/gnome/glib/glib-config-2.0.in,v
retrieving revision 1.1
diff -u -b -B -r1.1 glib-config-2.0.in
--- glib-config-2.0.in	2000/07/14 19:22:52	1.1
+++ glib-config-2.0.in	2000/11/08 15:20:26
@@ -99,7 +99,7 @@
 	libsp=""
 	libsa=""
 	if test "$lib_glib" = "yes"; then
-		libsp="$libsp -lglib-1.3"
+		libsp="$libsp -lglib-1.3 @G_LIBS@"
 	fi
 	if test "$lib_gobject" = "yes"; then
 		libsp="-lgobject-1.3 $libsp"