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

[John Ralls <jralls ceridwen us>]

On Jan 14, 2012, at 6:15 PM, Jesse van den Kieboom wrote:

2012/1/15 John Ralls <jralls ceridwen us>

On Jan 14, 2012, at 4:50 PM, Jesse van den Kieboom wrote:

> 2012/1/15 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.
>
> Hmm, I was planning to built for 10.4, 10.5 and 10.6. I'm not sure about the rpath thingie, I simply set PYTHONPATH in my launcher.

The rpath comes in when you have shared libraries (as opposed to loadable modules) that link against your python executable, BerkeleyDB for example. If what you're doing is working, don't worry about it.

Ok, I will have to check that for pygobject I suppose.

 

>
>
>
> > 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.
>
> Ok, I didn't manage to get it completely to work without patching glib, but I will try to simply built 32 bit binaries instead.

Really? What version of GLib? I thought it had been fixed 2.28 (which is what stable builds against).

I'm building against stable as defined in your module set. It still fails either specifying with-iconv=native or with-iconv=gnu (the first case becasue LIBICONV_H is still defined, the latter because libiconv_open is not present).

 

OK, thanks, I'll go have a look at git master.

Regards,

John Ralls