On Aug 31, 2009, at 10:43 PM, Andrew Stormont wrote:
I also had to do a similar thing to get glib-2.20.3 building on
Nexenta. :(
I don't think USE_LIBICONV_GNU is getting defined properly (I
configured with: --with-libiconv=gnu).
The point here is that /usr/lib/libiconv.dylib contains libiconv_open
for the
architecture i386, but not for the architecture x86_64:
[BigMacSL:/usr/lib] tuexen% nm -arch x86_64 libiconv.dylib | grep
libiconv_open
[BigMacSL:/usr/lib] tuexen% nm -arch i386 libiconv.dylib | grep
libiconv_open
000158cc T _libiconv_open
The same applies to Leopard. The only difference is that on certain
platforms
SnowLeopard builds a 64-bit binary by default. So it is not really an
SnowLeopard vs. Leopard issue, but a 32-bit vs. 64-bit issue.
Using --with-libiconv=gnu fails since the configure script tests
whether libiconv_open is contained in libiconv, which is not the case.
Any idea how to fix this besides just disabling the plausibility check
for 64-bit Mac OS X applications?
Best regards
Michael
Andy.
2009/8/31 Michael Tüxen <Michael.Tuexen@xxxxxxxxxxxxxxxxx>
Dear all,
when trying to compile glib-2.20.5 on a SnowLeopard system,
the compilation of glib/gconvert.c fails, when compiling as
a 64-bot binary.
To fix the problem, one has to replace
#if !defined(USE_LIBICONV_GNU) && defined (_LIBICONV_H)
#error GNU libiconv not in use but included iconv.h is from libiconv
#endif
by
#if !(defined(__APPLE__) && defined(__LP64__)) && !
defined(USE_LIBICONV_GNU) && defined (_LIBICONV_H)
#error GNU libiconv not in use but included iconv.h is from libiconv
#endif
Any chance to get this into a future release of glib?
Or is there a better fix?
Best regards
Michael
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
