py26-py2app @0.52 (and py25-py2app) cannot build apps on x86_64

[abarnert@…]

On Snow Leopard x86_64 (with the default x86_64 arch setting), py26-py2app installs properly. However, when you try to use it to build applications, it fails.

For example, if you download the MusicBrainz Picard source package, install the dependencies with MacPorts, and build everything, you can run it from the source tree. But when you then try to build an app bundle with:

$ /opt/local/bin/python2.6 setup.py py2app

It fails with "IOError: [Errno 2] No such file or directory: '/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py2app/apptemplate/prebuilt/main-x86_64'" and dumps you into pdb.

The first problem seems to be an incomplete (and incorrect) set of apptemplates. The port installs four prebuilt templates:

• main-fat: i386+ppc
• main-fat3: i386+ppc+x86_64
• main-intel: i386+ppc+x86_64
• main-universal: i386+ppc+ppc64+x86_64

As you can see, the main-x86_64 template is missing. (Also, at least one of the 4, main-intel, is wrong, and none of the 4 are useful anyway given that python was build x86_64-only.)

I tried to manually "lipo main-intel -extract x86_64 -output main-x86_64" as a workaround; after doing so, py2app now fails with ValueError("New Mach-O header is too large to relocate").

I tried using the Python 2.5 packages instead of 2.6, and again got the apptemplate problem.

I then tried building a parallel MacPorts with arch i386, and everything worked fine.

[jmroot (Joshua Root)]

Please remember to fill in the Port field and cc the maintainer.

[jmroot (Joshua Root)]

Looks like an upstream problem to me. They simply don't provide single-arch templates.

[abarnert@…]

Replying to jmr@…:

Looks like an upstream problem to me. They simply don't provide single-arch templates.

First, I'm not that familiar with MacPorts--does that mean I'm supposed to contact Ronald Oussoren, get it fixed upstream, and then let you know when to update the port, or something else?

I filed a bug at ​https://bitbucket.org/ronaldoussoren/py2app/issue/7/052-has-missing-broken-arch-templates-and

As you can see from that bug report, I discovered that this problem has apparently been fixed for 5 months, and should be in 0.5.3 (although it isn't mentioned in the 0.5.3 release notes), but for some reason that version still isn't at PyPI.

Meanwhile, I don't know MacPors policy, but it seems like a bad idea to offer ports that don't work at all. Is there some way to disable 0.5.2 for arch combinations that it can't handle (basically, anything but fat, fat3, and universal)?

[jmroot (Joshua Root)]

Replying to abarnert@…:

First, I'm not that familiar with MacPorts--does that mean I'm supposed to contact Ronald Oussoren, get it fixed upstream, and then let you know when to update the port, or something else?

Certainly from my perspective the easiest fix would be for him to release a new version. The existence of a patch changes things; if a new upstream release is not imminent, I can apply it to the port.

Is there some way to disable 0.5.2 for arch combinations that it can't handle (basically, anything but fat, fat3, and universal)?

Not really. It's dependent on how python is built anyway.

[abarnert@…]

Replying to jmr@…:

Certainly from my perspective the easiest fix would be for him to release a new version. The existence of a patch changes things; if a new upstream release is not imminent, I can apply it to the port.

I have no idea if it's imminent or not. Hopefully he just forgot to upload it, and now that he's been reminded it'll be soon, but who knows?

As for a patch: There seems to be an 0.5.3 tag in the repo, so I guess you could diff 0.5.3 against 0.5.2 and use that. Alternatively, just copy the 8 apptemplate files from the current version over what's included in 0.5.2, or post-process the apptemplates with lipo. (I tested both, and both seem to work.)

What about just making the port pull the tagged build out of hg instead of going to PyPI? It might be less work than building a patch manually. Or is that the kind of thing that would warrant a separate py2app-devel port and/or be flat-out inappropriate for MacPorts?

Is there some way to disable 0.5.2 for arch combinations that it can't handle (basically, anything but fat, fat3, and universal)?

Not really. It's dependent on how python is built anyway.

OK. In this case, the default MacPorts Python (at least on SL/x86_64 machines) can't use py2app, which is pretty bad. But I wouldn't want you to disable the port entirely, especially since I just setup an i386+ppc MacPorts tree that I'd like to work. :)

This isn't too urgent, at least for me; because of two other bugs that affect the same projects I wanted to py2app. (One of them is related to py2app: if you include most of the Qt4 libraries, or any equivalently-large set of stuff, you get a "New Mach-O header is too large to relocate" error when trying to py2app a 64-bit binary.) So, I'm backing off 64-bit builds for a while.

[francis@…]

Cc Me!

[jmroot (Joshua Root)]

r77543