After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 529806 - Cannot build in 64-bit Mac OS X due to libiconv
Cannot build in 64-bit Mac OS X due to libiconv
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: build
2.25.x
Other Mac OS
: Normal major
: ---
Assigned To: gtkdev
gtkdev
: 605045 665705 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-04-25 01:16 UTC by Glen Low
Modified: 2012-02-25 01:23 UTC
See Also:
GNOME target: ---
GNOME version: 2.29/2.30



Description Glen Low 2008-04-25 01:16:18 UTC
In the 64-bit Mac OS X libiconv library, iconv_open is defined but libiconv_open isn't.

The build for 64-bit Mac OS X then fails because configure thinks with_libiconv=no and found_iconv=yes. This leads to USE_LIBICONV_GNU not being defined, but this causes an #error in compiling glib/gconvert.c "GNU libiconv not in use but included iconv.h is from libiconv".

Notes:
1. libiconv_open is defined in 32-bit, but not in 64-bit. Thus the build does succeed in 32-bit.
2. There's no macro that defines iconv_open as libiconv_open. (I would suppose this is why configure wants to check for libiconv_open as well as iconv_open, especially since there's no direct use of libiconv_open in glib.)
3. I tried different combinations of --with-libiconv=yes|no|gnu|native to no avail. 

I'm attaching a patch that fences the #error in a 64-bit Mac OS X compile.

diff -ru glib-2.16.3/glib/gconvert.c glib-2.16.3.patched/glib/gconvert.c
--- glib-2.16.3/glib/gconvert.c	2008-04-08 11:47:29.000000000 +0800
+++ glib-2.16.3.patched/glib/gconvert.c	2008-04-24 14:41:44.000000000 +0800
@@ -48,12 +48,14 @@
 
 #include "glibintl.h"
 
+#if !defined(__APPLE_CC__) || !defined(__LP64__)
 #if defined(USE_LIBICONV_GNU) && !defined (_LIBICONV_H)
 #error GNU libiconv in use but included iconv.h not from libiconv
 #endif
 #if !defined(USE_LIBICONV_GNU) && defined (_LIBICONV_H)
 #error GNU libiconv not in use but included iconv.h is from libiconv
 #endif
+#endif
 
 #include "galias.h"
Comment 1 Glen Low 2008-04-26 04:59:02 UTC
To build for 64-bit Mac OS X, do a ./configure with CFLAGS="-arch ppc64 -arch x86_64" LDFLAGS="-arch ppc64 -arch x86_64".
Comment 2 Guy Harris 2009-12-23 09:33:41 UTC
*** Bug 605045 has been marked as a duplicate of this bug. ***
Comment 3 Guy Harris 2009-12-23 09:35:35 UTC
As of GLib 2.16.4, at least, I don't see any obvious place where GLib *cares* whether it's GNU or "native" libiconv ("native" presumably meaning "native GLib on a platform where the native iconv *isn't* GNU iconv).

Is there any reason for the configure script to bother checking for libiconv_open(), or for gconvert.c to check whether the included iconv.h appears to be appropriate for libiconv?  Is that check just done to handle machines where you have the native iconv *and* GNU iconv installed, to make sure you're not building with the header from one iconv and the libiconv from another iconv?

(As per 605045, closed as a dup, this is still happening on Snow Leopard - and, as Snow Leopard builds 64-bit by default on 64-bit machines, it happens by default on Snow Leopard on most machines.)
Comment 4 Javier Jardón (IRC: jjardon) 2009-12-23 15:50:05 UTC
Hello Guy,

Could you try if this is still an issue with the latest stable glib version (2.22)? Please, update the "version" field if this is still a issue in that version.

Thank you
Comment 5 Guy Harris 2009-12-23 19:11:28 UTC
Still happens in 2.22.3.

How do I update the Version: field?  It's displayed, but not editable, in my browser.
Comment 6 Javier Jardón (IRC: jjardon) 2009-12-23 19:19:01 UTC
Thank you for testing,

I've already updated the version field, sorry I think you have permissions to edit that field.
Comment 7 Stephen Fisher 2010-05-13 07:57:24 UTC
This is still an issue with glib 2.24.1 and the latest copy in the git repo web interface.  Can someone please update the version field on this bug or commit the patch ;).
Comment 8 Kristian Rietveld 2010-06-28 13:41:20 UTC
Still happens, I also use a patch locally to fence the error.  I haven't looked very closely yet what exactly is going on.
Comment 9 jessevdk@gmail.com 2012-01-15 11:48:40 UTC
Just to ping this bug, I'm running into this problem trying to build gedit for OS X. It would be nice if a fix would be committed to glib. I'm not sure though that the given patch is the right way to go. Maybe someone who is more familiar with the particularities of iconv could provide some comments on this?
Comment 10 John Ralls 2012-02-24 23:21:17 UTC
*** Bug 665705 has been marked as a duplicate of this bug. ***
Comment 11 John Ralls 2012-02-25 01:23:50 UTC
Well, I'm tired of dealing with this. I've just pushed a variation on the above,
--- a/glib/gconvert.c
+++ b/glib/gconvert.c
@@ -61,7 +61,8 @@
#if defined(USE_LIBICONV_GNU) && !defined (_LIBICONV_H)
#error GNU libiconv in use but included iconv.h not from libiconv
#endif
-#if !defined(USE_LIBICONV_GNU) && defined (_LIBICONV_H)
+#if !defined(USE_LIBICONV_GNU) && defined (_LIBICONV_H) \
+ && !defined (__APPLE_CC__) && !defined (__LP_64__)
#error GNU libiconv not in use but included iconv.h is from libiconv
#endif

and backported it to glib-2-30.