On Fri, 2010-02-26 at 19:10 +0100, Lukas Hetzenecker wrote:
> Hello,
>
> Am Freitag 26 Februar 2010 16:17:00 schrieb Giovanni Bajo:
> > On Tue, 2010-02-23 at 23:23 +0100, Lukas Hetzenecker wrote:
> > > I patched pyinstaller with the patch attached to this ticket:
> > > http://www.pyinstaller.org/ticket/152
> >
> > I'm happy to know it works. I don't specifically like the way the patch
> > is written, I will need to investigate the issue further.
>
> A better solution might be to use sys.executable - this will also work for a
> non-system python installation
That is an issue I wasn't aware of. My main concern is why it is ever
required a darwin-specific code. Both Windows and Linux manages to find
the Python dynamic library through special code in Configure.py; if you
look at config.dat (generated by Configure.py), it should contain a
dictionary called "EXE_dependencies" with the reference to the Python
dynamic module and all of its dependencies.
Given the bug description, I believe that the code in Configure.py fails
to find the Python library on some Macs. So, the patch shouldn't target
Build.py, but rather Configure.py. It might be that a darwin-specific
code path is required, but the correct place is Configure.py.
> > > File "/Users/Lukas/series60-
> > > remote/trunk/pc/build/pyi.darwin/series60_remote.darwin/outPYZ1.pyz/objc.
> > > _bridgesupport", line 58, in _parseBridgeSupport
> > > ValueError: Unknown typestr: ^{__CFAllocator=}
> >
> > This seems a problem with the way PyInstaller bundles pyobjc. Probably
> > this library requires some special support.
> >
> > I gave a quick look at the source code (objc/_bridgesupport.py, function
> > initFrameworkWrapper). It looks like:
> >
> > 1) It uses pkg_resources, which is not supported by PyInstaller. This
> > might or might no be a blocking problem.
> >
> > 2) It searches for files *.bridgesupport in the file system. This file
> > should probably be copied over by PyInstaller as they should be part of
> > the final bundle.
> >
> > So I would say that there is some work to do here. If you are willing to
> > investigate this together, I can give you some guidance. You will have
> > to study a little the internals of PyObjC (specifically, this
> > _bridgesupport module). Let me know if you are interested.
>
> Yes, some guidance would be great.
> I currently don't know much about the internals of PyObjC. In fact I even
> don't have OS X installed and it will take until monday that I've access to
> this machine again.
The problem appears to be in the function quoted above
(initFrameworkWrapper). A quick look gave me the impression that it
tries to find all the files with extension *.bridgesupport and parse
them at runtime. This would need to be confirmed.
I usually stuff prints in the package's code directly within
site-packages, and rerun PyInstaller; then I compare the output of the
program being run directly vs. the packaged version, until I understand
better what's going on. I suggest one-dir mode at this stage.
At this point, if you confirm that *.bridgesupport files are needed, you
can try to copy them over manually and see if you can make it work (eg:
maybe it defaults to the current directory somehow).
The next step would be to think of a way to "configure" pyobjc at
runtime (before your real application starts) so that it always finds
the *.bridgesupport files in a directoy we tell it. But let do one step
at a time.
--
Giovanni Bajo
Develer S.r.l.
http://www.develer.com
--
You received this message because you are subscribed to the Google Groups
"PyInstaller" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pyinstaller?hl=en.
