Opened 13 years ago

Closed 13 years ago

#27828 closed defect (fixed)

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

Reported by: abarnert@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 1.9.2
Keywords: Cc: jmroot (Joshua Root), francis@…
Port: py26-py2app py25-py2app

Description (last modified by ryandesign (Ryan Carsten Schmidt))

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.

Change History (8)

comment:1 Changed 13 years ago by jmroot (Joshua Root)

Cc: jmr@… added
Port: py26-py2app py25-py2app added

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

comment:2 Changed 13 years ago by jmroot (Joshua Root)

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

comment:3 in reply to:  1 ; Changed 13 years ago by 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)?

comment:4 in reply to:  3 ; Changed 13 years ago by 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.

comment:5 in reply to:  4 Changed 13 years ago by 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.

comment:6 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Description: modified (diff)

comment:7 Changed 13 years ago by francis@…

Cc: francis@… added

Cc Me!

comment:8 Changed 13 years ago by jmroot (Joshua Root)

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.