Re: [gtk-osx-users] python and iconv issues

[John Ralls <jralls ceridwen us>]

On Jan 14, 2012, at 2:52 PM, Jesse van den Kieboom wrote:

> I have been trying to compile different binaries (10.4/32, 10.5/64 and 10.6/64) on a Snow Leopard machine. Everything seems to be working (with some added patches), but there are two things remaining that I'm unsure of how to handle.
> 
> 1) Python
> I'm currently building python in jhbuild, in particular because otherwise the build for 10.4 does not succeed. I'm wondering though if this means that I will need to supply python with my package (I would rather not, since it takes a lot of space), or if I can still rely on the system python to be used? I read the comments on compiling python related stuff on a 64 bit machine (targetting a 32 bit sdk), but I'm not entirely sure I understand the consequences.
> 

I think that you have to build Python and include it in the bundle unless you are targeting the distribution to only one version of the OS. AFAIK Python libraries are not forward or backward compatible. Also note that if you are bundling a python application, python will need to be in Contents/MacOS so that the @executable-path/../Resources/lib/python2.7/site-packages rpaths work.


> 2) iconv
> I'm having trouble with iconv because the native cups of OS X links against iconv, but the one built in jhbuild does not expose the _iconv symbol (this happens at least on Lion). I briefly noticed another mail on this list about this issue, but didn't understand completely what was the right way to resolve the issue. Should I simply not compile iconv as part of jhbuild but instead link against the native one?

The reason for building libiconv is that Apple's libiconv x86_64 image doesn't include the libiconv_open and libiconv_close symbols (though the i386 image does). This used to be a problem with GLib because it didn't correctly recognize that Apple's libiconv wasn't Gnu and tried to use those symbols. I think that that bug in GLib is fixed; you can also avoid the problem altogether by not trying to build an x86_64 image. While it's possible to build intel-universal Gtk apps, it's a pain in the rear (see http://sourceforge.net/apps/phpbb/gtk-osx/viewtopic.php?f=3&t=70) and I don't think that there's any real benefit to it (or 64-bit) for 99% of applications.

Regards,
John Ralls