I'm the maintainer of macholib as well (and the rest of the py2app stack)

Ronald

Sent from my iPad

On 25 nov. 2012, at 21:02, Christian Tismer <tis...@stackless.com> wrote:

> Hi Ronald,
> 
> maybe my way to reply to this thread was the wrong approach.
> I thought I had found the reason why Michael had problems,
> because I hit that, too.
> 
> But it was not a py2app question at all that I wanted to ask.
> 
> Instead I thought you are the current maintainer of macholib,
> and I wanted to point you at a possible bug in there that is
> hidden since a long time.
> 
> I will ask a specific question about what I found and contact
> the author of macholib.
> 
> Is it you, or still Bob Ippolito?
> 
> Sorry for being confusing ;-)
> 
> 
> Cheers - Chris
> 
> On 11/25/12 2:36 PM, Ronald Oussoren wrote:
>> On 24 Nov, 2012, at 21:50, Christian Tismer <tis...@stackless.com> wrote:
>> 
>>> Howdy,
>>> 
>>> On 31.05.12 21:46, Michael McCracken wrote:
>>>> New user, so new thread, in reference to "(PyQt and py2app) Gui starts
>>>> in IDLE but not as app".
>>>> 
>>>> This happens when Qt loads image plugins from the
>>>> system location (likely set during Qt's configure), which
>>>> then load the system Qt.
>>>> 
>>>> The problem and a workaround are described here:
>>>> http://lists.trolltech.com/qt-interest/2008-09/thread00258-0.html
>>>> 
>>>> py2app's PyQt sample doesn't exercise enough of Qt to hit this problem.
>>>> I'm not sure exactly what part of Qt you'd need to trigger it, but
>>>> I guess the Color Picker might work.
>>>> 
>>>> The quick way, if you know you don't need these plugins, is to
>>>> create an empty qt.conf file at MyApp.app/Contents/Resources/qt.conf.
>>> ...
>>> 
>>> I've hit a similar problem when trying to build a stand-alone pyside.
>>> Starting with a modified setup.py (not yet ready), I created a working
>>> pyside for virtualenv.
>>> The missing part was support for 'setup.py --standalone', so I found
>>> macholib which does a great job in creating the missing bits.
>> I don't quite understand, does "python setup.py py2app" not work with pyside 
>> in a virtualenv?
>> 
>> If so: did you have to do anything special to build such a pyside?
>> 
>>> I simply used a few lines of Python to try out if macholib works for me,
>>> like so:
>>> 
>>>> from macholib.MachOStandalone import MachOStandalone
>>>> from macholib.util import strip_files
>>>> path='/Users/tismer/src/daniel/pydica/lib/python2.7/site-packages/PySide'
>>>> files = MachOStandalone(path).run(contents='@rpath/Contents')
>> You can also use "python -m macholib standalone" with recent releases
>> of macholib.
>> 
>>> This works great so far, but the generated pyside complains about duplicate 
>>> libraries.
>>> When I uninstall Qt, it does not find its image plugins.
>>> 
>>> I guess there is a bug somewhere, which causes the following observation:
>> This looks like a problem that is hopefully fixed for PyQt: Qt probably uses 
>> the
>> wrong prefix to find its addons (the virtualenv location instead of the 
>> application bundle),
>> and that causes it to load an image plugin from the virtualenv which again 
>> pulls
>> in libQt from the virtualenv and then you end up with duplicate symbols and 
>> later
>> on a crash.
>> 
>> For PyQt this was fixed by loading a qt.conf into the application bundle, I 
>> added
>> simular code for pyside, but that obviously didn't work.
>> 
>>> $ otool -L /usr/local/Cellar/qt/4.8.3/plugins/imageformats/libqtiff.dylib
>>> /usr/local/Cellar/qt/4.8.3/plugins/imageformats/libqtiff.dylib:
>>>    libqtiff.dylib (compatibility version 0.0.0, current version 0.0.0)
>>> /usr/local/Cellar/qt/4.8.3/lib/QtGui.framework/Versions/4/QtGui 
>>> (compatibility version 4.8.0, current version 4.8.3)
>>> /usr/local/Cellar/qt/4.8.3/lib/QtCore.framework/Versions/4/QtCore 
>>> (compatibility version 4.8.0, current version 4.8.3)
>>>    /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 
>>> 1.2.5)
>>>    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 
>>> 56.0.0)
>>>    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 
>>> 169.3.0)
>>>    /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 
>>> 1669.0.0)
>>> 
>>> $ otool -L 
>>> /Users/tismer/src/daniel/pydica/lib/python2.7/site-packages/PySide/plugins/imageformats/libqtiff.dylib
>>> /Users/tismer/src/daniel/pydica/lib/python2.7/site-packages/PySide/plugins/imageformats/libqtiff.dylib:
>>>    @rpath/Contents/mageformats/libqtiff.dylib (compatibility version 0.0.0, 
>>> current version 0.0.0)
>>> @rpath/Contents/Frameworks/QtGui.framework/Versions/4/QtGui (compatibility 
>>> version 4.8.0, current version 4.8.3)
>>> @rpath/Contents/Frameworks/QtCore.framework/Versions/4/QtCore 
>>> (compatibility version 4.8.0, current version 4.8.3)
>>>    /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 
>>> 1.2.5)
>>>    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 
>>> 56.0.0)
>>>    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 
>>> 169.3.0)
>>>    /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 
>>> 1669.0.0)
>>> 
>>> The problem might be this line:
>>> @rpath/Contents/mageformats/libqtiff.dylib
>>> 
>>> The "i" from "imageformats" is missing!
>>> 
>>> This _might_ be related to the unusual case that "libqtiff" has no path at 
>>> all, or something else
>>> is funny, and we end up with a name that will not be found at all.
>>> Then the loader finds the plugin in the installed Qt, which causes it to 
>>> load everything
>>> again from there.
>>> 
>>> Is that a possible explaining?
>>> I just found that and had not the time to debug it thoroughly.
>> Did you use the most recent release of py2app?
>> 
>> If so, there is pyside support code in py2app/recipes/pyside.py and support 
>> code
>> for PyQt in py2app/recipes/sip.py.  The latter works with PyQt on my machine,
>> although with a system-wide install not an installation in a virtualenv.
>> 
>> Ronald
> 
> 
> -- 
> Christian Tismer             :^)   <mailto:tis...@stackless.com>
> Software Consulting          :     Have a break! Take a ride on Python's
> Karl-Liebknecht-Str. 121     :    *Starship* http://starship.python.net/
> 14482 Potsdam                :     PGP key -> http://pgp.uni-mainz.de
> phone +49 173 24 18 776  fax +49 (30) 700143-0023
> PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
>      whom do you want to sponsor today?   http://www.stackless.com/
> 
_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Reply via email to