> I'm stuck again with the next issue: starting the PyQt4 app on a pristine
> mac results in:

> Mac OS X Version 10.4.11 (Build 8S165)
> 2009-07-02 10:06:59 +0200
> 2009-07-02 10:07:03.260 SystemUIServer[120] lang is:de
> Workaround Bonjour: Unknown error: 0
> Traceback (most recent call last):
>   File "<string>", line 34, in <module>
>   File "/Users/hp/Desktop/PyQt-Devel/creport/tools/pyinstaller/iu.py",
> line 480, in importHook File
> "/Users/hp/Desktop/PyQt-Devel/creport/tools/pyinstaller/iu.py", line 498,
> in doimport File
> "/Users/hp/Desktop/PyQt-Devel/creport/tools/pyinstaller/iu.py", line 300,
> in getmod File
> "/Users/hp/Desktop/PyQt-Devel/creport/tools/pyinstaller/archive.py", line
> 468, in getmod File
> "/Users/hp/Desktop/PyQt-Devel/creport/tools/pyinstaller/iu.py", line 109,
> in getmod ImportError:
> dlopen(/Applications/CReport.app/Contents/MacOS/PyQt4.QtCore.so, 2):
> Library not loaded: QtCore.framework/Versions/4/QtCore Referenced from:
> /Applications/CReport.app/Contents/MacOS/PyQt4.QtCore.so Reason: image
> not found

> Apart from the devel path leaking into the app, it obviously cannot
> locate the QtCore library. BTW, there where issues with BUNDLE(), I
> examine later. For now, the manually created bundle with
> .app/Contents/MacOS containing everything from the one-dir run should be
> sufficient. Here the MacOS folder content:

> $ ls -l /Applications/CReport.app/Contents/MacOS/
> total 100352
> -rwxrwxr-x   1 root  admin  1331492 Jul  2 00:21 CReport
> -rwxrwxr-x   1 root  admin    85876 Apr 16 09:23 MacOS.so
> -rwxrwxr-x   1 root  admin   118528 Apr 16 09:23 Nav.so
> -rwxrwxr-x   1 root  admin  2078692 Jul  1 23:47 PyQt4.QtCore.so
> -rwxrwxr-x   1 root  admin  9433500 Jul  1 23:47 PyQt4.QtGui.so
> -rwxrwxr-x   1 root  admin  9367288 Apr 16 09:28 Python
> -rwxrwxr-x   1 root  admin   131676 Apr 16 09:24 _AE.so
> -rwxrwxr-x   1 root  admin   426328 Apr 16 09:24 _Ctl.so
> -rwxrwxr-x   1 root  admin   148036 Apr 16 09:24 _Dlg.so
> -rwxrwxr-x   1 root  admin    78336 Apr 16 09:25 _Evt.so
> -rwxrwxr-x   1 root  admin   260632 Apr 16 09:25 _File.so
> -rwxrwxr-x   1 root  admin   246392 Apr 16 09:26 _Menu.so
> -rwxrwxr-x   1 root  admin   458268 Apr 16 09:26 _Qd.so
> -rwxrwxr-x   1 root  admin   147044 Apr 16 09:26 _Res.so
> -rwxrwxr-x   1 root  admin   258092 Apr 16 09:27 _Win.so
> -rwxrwxr-x   1 root  admin    54644 Apr 16 09:18 _bisect.so
> -rwxrwxr-x   1 root  admin   150336 Apr 16 09:18 _collections.so
> -rwxrwxr-x   1 root  admin   653552 Apr 16 09:28 _ctypes.so
> -rwxrwxr-x   1 root  admin    59956 Apr 16 09:18 _functools.so
> -rwxrwxr-x   1 root  admin    77520 Apr 16 09:20 _hashlib.so
> -rwxrwxr-x   1 root  admin    81136 Apr 16 09:18 _heapq.so
> -rwxrwxr-x   1 root  admin    75780 Apr 16 09:19 _locale.so
> -rwxrwxr-x   1 root  admin   142620 Apr 16 09:22 _multibytecodec.so
> -rwxrwxr-x   1 root  admin   159072 Apr 16 09:23 _multiprocessing.so
> -rwxrwxr-x   1 root  admin    70516 Apr 16 09:18 _random.so
> -rwxrwxr-x   1 root  admin    96432 Apr 16 09:20 _sha256.so
> -rwxrwxr-x   1 root  admin   179272 Apr 16 09:20 _sha512.so
> -rwxrwxr-x   1 root  admin   234228 Apr 16 09:20 _socket.so
> -rwxrwxr-x   1 root  admin   189384 Apr 16 09:20 _ssl.so
> -rwxrwxr-x   1 root  admin   166232 Apr 16 09:17 _struct.so
> -rwxrwxr-x   1 root  admin    48208 Apr 16 09:17 _weakref.so
> -rwxrwxr-x   1 root  admin   178168 Apr 16 09:17 array.so
> -rwxrwxr-x   1 root  admin   116096 Apr 16 09:21 binascii.so
> -rwxrwxr-x   1 root  admin   344800 Apr 16 09:21 bz2.so
> -rwxrwxr-x   1 root  admin   359340 Apr 16 09:19 cPickle.so
> -rwxrwxr-x   1 root  admin    91936 Apr 16 09:19 cStringIO.so
> -rwxrwxr-x   1 root  admin   395388 Apr 16 09:18 datetime.so
> -rwxrwxr-x   1 root  admin    71444 Apr 16 09:19 fcntl.so
> drwxrwxr-x   4 root  admin      136 Jul  2 03:07 i18n
> -rwxrwxr-x   1 root  admin    73416 Apr 16 09:24 icglue.so
> -rwxrwxr-x   1 root  admin   211632 Apr 16 09:18 itertools.so
> -rwxrwxr-x   1 root  admin  7895472 Apr  1 07:45 libSystem.B.dylib
> -rwxrwxr-x   1 root  admin  4606384 Feb 11 04:18 libcrypto.0.9.7.dylib
> -rwxrwxr-x   1 root  admin   264016 Oct  6  2007 libgcc_s.1.dylib
> -rwxrwxr-x   1 root  admin   142400 Jan 26 09:49 libmathCommon.A.dylib
> -rwxrwxr-x   1 root  admin   373984 Jan 26 10:15 libmx.A.dylib
> -rwxrwxr-x   1 root  admin   714756 Apr 16 09:01 libncurses.5.dylib
> -rwxrwxr-x   1 root  admin   915632 Feb 11 04:18 libssl.0.9.7.dylib
> -rwxrwxr-x   1 root  admin  3035296 Sep 24  2007 libstdc++.6.dylib
> -rwxrwxr-x   1 root  admin   346144 Sep 24  2007 libz.1.dylib
> -rwxrwxr-x   1 root  admin   103616 Apr 16 09:18 math.so
> -rwxrwxr-x   1 root  admin   104328 Apr 16 09:19 mmap.so
> -rwxrwxr-x   1 root  admin   117904 Apr 16 09:18 operator.so
> -rwxrwxr-x   1 root  admin  1220768 Apr 16 09:22 pyexpat.so
> drwxrwxr-x   6 root  admin      204 Jul  2 00:20 qt4_plugins
> -rwxrwxr-x   1 root  admin   577320 Apr 16 09:19 readline.so
> -rwxrwxr-x   1 root  admin   116492 Apr 16 09:19 select.so
> -rwxrwxr-x   1 root  admin    80364 Jul  1 23:15 sip.so
> -rwxrwxr-x   1 root  admin   130364 Apr 16 09:18 strop.so
> -rwxrwxr-x   1 root  admin    69568 Apr 16 09:21 termios.so
> -rwxrwxr-x   1 root  admin    88328 Apr 16 09:18 time.so
> -rwxrwxr-x   1 root  admin  1253792 Apr 16 09:19 unicodedata.so
> -rwxrwxr-x   1 root  admin   250064 Apr 16 09:21 zlib.so

> Looks like the PyQt modules try to access QtCore.framework/Versions/4
> which seem to be missing:

> $ otool -L CReport.app/Contents/MacOS/PyQt4.Qt*
> CReport.app/Contents/MacOS/PyQt4.QtCore.so:
>         QtCore.framework/Versions/4/QtCore (compatibility version 4.5.0,
> current version 4.5.2) /usr/lib/libz.1.dylib (compatibility version
> 1.0.0, current version 1.2.3) /usr/lib/libSystem.B.dylib (compatibility
> version 1.0.0, current version 111.1.4)
> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Appli
>cationServices (compatibility version 1.0.0, current version 34.0.0)
>         /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
> version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
> current version 1.0.0) CReport.app/Contents/MacOS/PyQt4.QtGui.so:
>         QtGui.framework/Versions/4/QtGui (compatibility version 4.5.0,
> current version 4.5.2)
> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
> (compatibility version 2.0.0, current version 136.0.0)
> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
> (compatibility version 45.0.0, current version 949.46.0)
> QtCore.framework/Versions/4/QtCore (compatibility version 4.5.0, current
> version 4.5.2) /usr/lib/libz.1.dylib (compatibility version 1.0.0,
> current version 1.2.3) /usr/lib/libSystem.B.dylib (compatibility version
> 1.0.0, current version 111.1.4) /usr/lib/libstdc++.6.dylib (compatibility
> version 7.0.0, current version 7.4.0) /usr/lib/libgcc_s.1.dylib
> (compatibility version 1.0.0, current version 1.0.0)

> Shouldn't this work out of the box? I would very much like to keep the
> original Qt build, I'm using here. Needless to say, running it with
> Qt installed, works fine. (There seem to be similar issues with the
> qt4_plugins location which gets picked up from the systems Qt
> installation, rather then those incuded in the package.

> Current packages installed on the developer machine:
> xcode313_2736_developerdvd.dmg
> python-2.6.2-macosx2009-04-16.dmg
> qt-sdk-mac-opensource-2009.03.dmg
> sip-4.8.1.tar.gz
> PyQt-mac-gpl-4.5.1.tar.gz (with minor Configure.py patch for Qt 4.5.2
> compatibility) http://svn.pyinstaller.org/trunk:685

> Any ideas on what's going wrong here?

> > $ otool -L CReport.app/Contents/MacOS/PyQt4.Qt*
> > CReport.app/Contents/MacOS/PyQt4.QtCore.so:
> >         QtCore.framework/Versions/4/QtCore (compatibility version
> > 4.5.0, current version 4.5.2) /usr/lib/libz.1.dylib (compatibility
> > version 1.0.0, current version 1.2.3) /usr/lib/libSystem.B.dylib
> > (compatibility version 1.0.0, current version 111.1.4)
> > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/App
> >li cationServices (compatibility version 1.0.0, current version 34.0.0)
> > /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
> > version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
> > current version 1.0.0) CReport.app/Contents/MacOS/PyQt4.QtGui.so:
> > QtGui.framework/Versions/4/QtGui (compatibility version 4.5.0, current
> > version 4.5.2)
> > /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
> > (compatibility version 2.0.0, current version 136.0.0)
> > /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
> > (compatibility version 45.0.0, current version 949.46.0)
> > QtCore.framework/Versions/4/QtCore (compatibility version 4.5.0,
> > current version 4.5.2) /usr/lib/libz.1.dylib (compatibility version
> > 1.0.0, current version 1.2.3) /usr/lib/libSystem.B.dylib (compatibility
> > version 1.0.0, current version 111.1.4) /usr/lib/libstdc++.6.dylib
> > (compatibility version 7.0.0, current version 7.4.0)
> > /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
> > 1.0.0)

> > Shouldn't this work out of the box? I would very much like to keep the
> > original Qt build, I'm using here. Needless to say, running it with
> > Qt installed, works fine. (There seem to be similar issues with the
> > qt4_plugins location which gets picked up from the systems Qt
> > installation, rather then those incuded in the package.

> > Current packages installed on the developer machine:
> > xcode313_2736_developerdvd.dmg
> > python-2.6.2-macosx2009-04-16.dmg
> > qt-sdk-mac-opensource-2009.03.dmg
> > sip-4.8.1.tar.gz
> > PyQt-mac-gpl-4.5.1.tar.gz (with minor Configure.py patch for Qt 4.5.2
> > compatibility) http://svn.pyinstaller.org/trunk:685

> > Any ideas on what's going wrong here?

> Okay, found it: http://doc.trolltech.com/4.5/deployment-mac.html

> Seems to me, that there's quite a bit of way to go before this all is
> usable painlessly.

> Yes, it should work out of the box, and I have sucessfully managed to
> ship PyQt applications on Mac.

> It might be related to the fact that PyInstaller seems not to set
> DYLD_LIBRARY_PATH correctly in one-dir mode.

> > Yes, it should work out of the box, and I have sucessfully managed to
> > ship PyQt applications on Mac.

> > It might be related to the fact that PyInstaller seems not to set
> > DYLD_LIBRARY_PATH correctly in one-dir mode.

> Hmm, given that the libs are missing, how could setting a environment
> variable fix that problem?

> No, it doesn't, but since the analyse part is the same, it cannot.

> Did you really shipped apps, based on a current Qt framework build, and it
> worked out of the box (without Qt installed on the target systems)?!?

> cd .app/Contents
> md Framework
> cp -R /Library/Frameworks/Qt{Core,Gui}.framework Framework
> find Framework -depth -name Headers -exec rm -r {} \;
> find Framework -depth -name \*_debug\* -exec rm -r {} \;

> # treat QtCore
> install_name_tool -id \
> @executable_path/../Frameworks/QtCore.framework/Versions/4.0/QtCore \
> QtCore.framework/Versions/4.0/QtCore

> install_name_tool -change QtCore.framework/Versions/4/QtCore \
> @executable_path/../Frameworks/QtCore.framework/Versions/4.0/QtCore \
> QtCore.framework/Versions/4.0/QtCore

> # treat QtGui
> install_name_tool -id \
> @executable_path/../Frameworks/QtGui.framework/Versions/4.0/QtGui \
> QtGui.framework/Versions/4.0/QtGui

> install_name_tool -change QtCore.framework/Versions/4/QtCore \
> @executable_path/../Frameworks/QtCore.framework/Versions/4.0/QtCore \
> QtGui.framework/Versions/4.0/QtGui

> # treat PyQt4.QtCore
> install_name_tool -change QtCore.framework/Versions/4/QtCore \
> @executable_path/../Frameworks/QtCore.framework/Versions/4.0/QtCore ../MacOS/PyQt4.QtCore.so

> # treat PyQt4.QtGui
> install_name_tool -change QtCore.framework/Versions/4/QtCore \
> @executable_path/../Frameworks/QtCore.framework/Versions/4.0/QtCore ../MacOS/PyQt4.QtGui.so

> install_name_tool -change QtGui.framework/Versions/4/QtGui \
> @executable_path/../Frameworks/QtGui.framework/Versions/4.0/QtGui ../MacOS/PyQt4.QtGui.so

> # check, if something is still missing
> otool -L ../MacOS/PyQt4.Qt*.so QtCore.framework/QtCore QtGui.framework/QtGui

> You see, the whole mess is asking for automatic treatment. What I'm thinking
> about, is getting rid of the Framework junk, and simply throw the lib files
> QtCore, QtGui, etc into "the" dir (renaming them to Qt*.so), and do the
> adjustments as outlined above, but I haven't tried this yet.

> > > Yes, it should work out of the box, and I have sucessfully managed to
> > > ship PyQt applications on Mac.

> > > It might be related to the fact that PyInstaller seems not to set
> > > DYLD_LIBRARY_PATH correctly in one-dir mode.

> > Hmm, given that the libs are missing, how could setting a environment
> > variable fix that problem?

> Sorry, I had misread your original mail.

> > No, it doesn't, but since the analyse part is the same, it cannot.

> > Did you really shipped apps, based on a current Qt framework build, and
> > it worked out of the box (without Qt installed on the target
> > systems)?!?

> Yes. I'm not 100% sure my deployment Mac has the standard Qt framework
> though; I'll have to check.

> I still can't see what it is going on. mf.py (which is the dependency
> analyzer) should be able to find the Qt libraries from the PyQt4 ones.
> What happens if you run "bindepend.py PyQt4.QtCore4.so"? Does it list Qt
> dependencies? Under what path?

> > cd .app/Contents
> > md Framework
> > cp -R /Library/Frameworks/Qt{Core,Gui}.framework Framework
> > find Framework -depth -name Headers -exec rm -r {} \;
> > find Framework -depth -name \*_debug\* -exec rm -r {} \;

> > # treat QtCore
> > install_name_tool -id \
> > @executable_path/../Frameworks/QtCore.framework/Versions/4.0/QtCore \
> > QtCore.framework/Versions/4.0/QtCore

> > install_name_tool -change QtCore.framework/Versions/4/QtCore \
> > @executable_path/../Frameworks/QtCore.framework/Versions/4.0/QtCore \
> > QtCore.framework/Versions/4.0/QtCore

> > # treat QtGui
> > install_name_tool -id \
> > @executable_path/../Frameworks/QtGui.framework/Versions/4.0/QtGui \
> > QtGui.framework/Versions/4.0/QtGui

> > install_name_tool -change QtCore.framework/Versions/4/QtCore \
> > @executable_path/../Frameworks/QtCore.framework/Versions/4.0/QtCore \
> > QtGui.framework/Versions/4.0/QtGui

> > # treat PyQt4.QtCore
> > install_name_tool -change QtCore.framework/Versions/4/QtCore \
> > @executable_path/../Frameworks/QtCore.framework/Versions/4.0/QtCore
> > ../MacOS/PyQt4.QtCore.so

> > # treat PyQt4.QtGui
> > install_name_tool -change QtCore.framework/Versions/4/QtCore \
> > @executable_path/../Frameworks/QtCore.framework/Versions/4.0/QtCore
> > ../MacOS/PyQt4.QtGui.so

> > install_name_tool -change QtGui.framework/Versions/4/QtGui \
> > @executable_path/../Frameworks/QtGui.framework/Versions/4.0/QtGui
> > ../MacOS/PyQt4.QtGui.so

> > # check, if something is still missing
> > otool -L ../MacOS/PyQt4.Qt*.so QtCore.framework/QtCore
> > QtGui.framework/QtGui

> > You see, the whole mess is asking for automatic treatment. What I'm
> > thinking about, is getting rid of the Framework junk, and simply throw
> > the lib files QtCore, QtGui, etc into "the" dir (renaming them to
> > Qt*.so), and do the adjustments as outlined above, but I haven't tried
> > this yet.

> Yes it would be better to just put everything inside the output
> directory, like we do on other platforms (unless dyld makes this really
> impossible -- which I hope it does not).

> The install_name_tool trick shouldn't be necessary: I used to do it
> automatically in PyInstaller, but it turned out to have compatibility
> problems across different Mac OSX versions (I don't recall details) and
> setting DYLD_LIBRARY_PATH instead was just as effective.

> This is a totally different topic, as PyInstaller treats qt4_plugins
> mostly as data files. We'll have to find out why hook-PyQt4.Qt*.py don't
> find the Qt4 plugins directory.

> It looks like QT_PLUGIN_PATH is set correctly, and they also appear
> altogether, but those plugins bind with nearly all Qt libs in existence,
> and this dependancy is not handled correctly, yet.

> > Yes it would be better to just put everything inside the output
> > directory, like we do on other platforms (unless dyld makes this really
> > impossible -- which I hope it does not).

> Am Freitag, 3. Juli 2009 schrieb Giovanni Bajo:
>> On gio, 2009-07-02 at 21:56 +0200, Hans-Peter Jansen wrote:
>>> Am Donnerstag, 2. Juli 2009 schrieb Giovanni Bajo:
>>>> On 7/2/2009 11:23 AM, Hans-Peter Jansen wrote:
>>>>> Shouldn't this work out of the box? I would very much like to keep
>>>>> the original Qt build, I'm using here. Needless to say, running it
>>>>> with Qt installed, works fine.
>>>> Yes, it should work out of the box, and I have sucessfully managed to
>>>> ship PyQt applications on Mac.

>>>> It might be related to the fact that PyInstaller seems not to set
>>>> DYLD_LIBRARY_PATH correctly in one-dir mode.
>>> Hmm, given that the libs are missing, how could setting a environment
>>> variable fix that problem?
>> Sorry, I had misread your original mail.

> Excuse me, I don't wanted to sound rude. I tend to be explicite sometimes..

>>> Did you really shipped apps, based on a current Qt framework build, and
>>> it worked out of the box (without Qt installed on the target
>>> systems)?!?
>> Yes. I'm not 100% sure my deployment Mac has the standard Qt framework
>> though; I'll have to check.

>> I still can't see what it is going on. mf.py (which is the dependency
>> analyzer) should be able to find the Qt libraries from the PyQt4 ones.
>> What happens if you run "bindepend.py PyQt4.QtCore4.so"? Does it list Qt
>> dependencies? Under what path?

> $ tools/pyinstaller/bindepend.py dist/CReport/PyQt4.QtCore.so
> dist/CReport/PyQt4.QtCore.so E: cannot find path QtCore.framework/Versions/4/QtCore
> (needed by dist/CReport/PyQt4.QtCore.so)
> ['/usr/lib/libz.1.dylib', '/usr/lib/libSystem.B.dylib',
> '/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Applic ationServices',
> '/usr/lib/libstdc++.6.dylib', '/usr/lib/libgcc_s.1.dylib']

> Obviously, Qt uses a path relative to /Library/Frameworks.

> With the gross hack appended, pyinstaller got rid of the error and added Qt{Core,Gui}:

> $ python tools/pyinstaller/bindepend.py dist/CReport/PyQt4.QtCore.so
> dist/CReport/PyQt4.QtCore.so ['/Library/Frameworks/QtCore.framework/Versions/4/QtCore',
> '/usr/lib/libz.1.dylib', '/usr/lib/libSystem.B.dylib',
> '/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Applic ationServices',
> '/usr/lib/libstdc++.6.dylib', '/usr/lib/libgcc_s.1.dylib']

>>> cd .app/Contents
>>> md Framework
>>> cp -R /Library/Frameworks/Qt{Core,Gui}.framework Framework
>>> find Framework -depth -name Headers -exec rm -r {} \;
>>> find Framework -depth -name \*_debug\* -exec rm -r {} \;

>>> # treat QtCore
>>> install_name_tool -id \
>>> @executable_path/../Frameworks/QtCore.framework/Versions/4.0/QtCore \
>>> QtCore.framework/Versions/4.0/QtCore

>>> install_name_tool -change QtCore.framework/Versions/4/QtCore \
>>> @executable_path/../Frameworks/QtCore.framework/Versions/4.0/QtCore \
>>> QtCore.framework/Versions/4.0/QtCore

>>> # treat QtGui
>>> install_name_tool -id \
>>> @executable_path/../Frameworks/QtGui.framework/Versions/4.0/QtGui \
>>> QtGui.framework/Versions/4.0/QtGui

>>> install_name_tool -change QtCore.framework/Versions/4/QtCore \
>>> @executable_path/../Frameworks/QtCore.framework/Versions/4.0/QtCore \
>>> QtGui.framework/Versions/4.0/QtGui

>>> # treat PyQt4.QtCore
>>> install_name_tool -change QtCore.framework/Versions/4/QtCore \
>>> @executable_path/../Frameworks/QtCore.framework/Versions/4.0/QtCore
>>> ../MacOS/PyQt4.QtCore.so

>>> # treat PyQt4.QtGui
>>> install_name_tool -change QtCore.framework/Versions/4/QtCore \
>>> @executable_path/../Frameworks/QtCore.framework/Versions/4.0/QtCore
>>> ../MacOS/PyQt4.QtGui.so

>>> install_name_tool -change QtGui.framework/Versions/4/QtGui \
>>> @executable_path/../Frameworks/QtGui.framework/Versions/4.0/QtGui
>>> ../MacOS/PyQt4.QtGui.so

>>> # check, if something is still missing
>>> otool -L ../MacOS/PyQt4.Qt*.so QtCore.framework/QtCore
>>> QtGui.framework/QtGui

>>> You see, the whole mess is asking for automatic treatment. What I'm
>>> thinking about, is getting rid of the Framework junk, and simply throw
>>> the lib files QtCore, QtGui, etc into "the" dir (renaming them to
>>> Qt*.so), and do the adjustments as outlined above, but I haven't tried
>>> this yet.
>> Yes it would be better to just put everything inside the output
>> directory, like we do on other platforms (unless dyld makes this really
>> impossible -- which I hope it does not).

>> The install_name_tool trick shouldn't be necessary: I used to do it
>> automatically in PyInstaller, but it turned out to have compatibility
>> problems across different Mac OSX versions (I don't recall details) and
>> setting DYLD_LIBRARY_PATH instead was just as effective.

> Okay, that's missing as well:
> output from print os.environ
> {'SHELL': '/bin/bash', 'QT_PLUGIN_PATH': 'qt4_plugins:',
> 'PYTHONPATH': '/Applications/CReport.app/Contents/MacOS',
> 'SECURITYSESSIONID': '6052c0', '__CF_USER_TEXT_ENCODING': '0x1F5:0:3',
> 'USER': 'hp', 'HOME': '/Users/hp', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin'}

> Traceback (most recent call last):
>   File "<string>", line 36, in <module>
>   File "/Users/hp/Desktop/PyQt-Devel/creport/tools/pyinstaller/iu.py", line 480, in importHook
>   File "/Users/hp/Desktop/PyQt-Devel/creport/tools/pyinstaller/iu.py", line 498, in doimport
>   File "/Users/hp/Desktop/PyQt-Devel/creport/tools/pyinstaller/iu.py", line 300, in getmod
>   File "/Users/hp/Desktop/PyQt-Devel/creport/tools/pyinstaller/archive.py", line 468, in getmod
>   File "/Users/hp/Desktop/PyQt-Devel/creport/tools/pyinstaller/iu.py", line 109, in getmod
> ImportError: dlopen(/Applications/CReport.app/Contents/MacOS/PyQt4.QtCore.so, 2):
> Library not loaded: QtCore.framework/Versions/4/QtCore
>   Referenced from: /Applications/CReport.app/Contents/MacOS/PyQt4.QtCore.so
>   Reason: image not found

> I tried to find the right spot for adding it, but failed. source/linux/main.s
> looks to me, like it should appear (as long as workpath is not empty).

> It looks like QT_PLUGIN_PATH is set correctly, and they also appear
> altogether, but those plugins bind with nearly all Qt libs in existence,
> and this dependancy is not handled correctly, yet.

> > $ python tools/pyinstaller/bindepend.py dist/CReport/PyQt4.QtCore.so
> > dist/CReport/PyQt4.QtCore.so
> > ['/Library/Frameworks/QtCore.framework/Versions/4/QtCore',
> > '/usr/lib/libz.1.dylib', '/usr/lib/libSystem.B.dylib',
> > '/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Ap
> >plicationServices', '/usr/lib/libstdc++.6.dylib',
> > '/usr/lib/libgcc_s.1.dylib']

> OK, this requires some Mac Guru to tell us how dyld resolves the
> dependencies at runtime. I thought otool -L always output absolute
> paths, but if that's not the case, how are we supposed to find out the
> absolute paths?

> I don't have a Mac right now. Maybe someone can chime in?

> In one-dir mode, I *believe* that workpath is empty (I'm not sure I
> fully understand the code in there). Try putting some debug messages in
> there to debug.

> Anyway, to test if it's the right approach, it is of course sufficient
> to manually set DYLD_LIBRARY_PATH:

>   $ DYLD_LIBRARY_PATH=`pwd` ./myapp

> If this works, at least we know that we don't need to play any
> install_name_tool game.

> >> This is a totally different topic, as PyInstaller treats qt4_plugins
> >> mostly as data files.

> > It looks like QT_PLUGIN_PATH is set correctly, and they also appear
> > altogether, but those plugins bind with nearly all Qt libs in
> > existence, and this dependancy is not handled correctly, yet.

> This should be fixed wherever we fix the PyQt <-> Qt dependency, that is
> with DYLD_LIBRARY_PATH (hopefully).

> Index: bindepend.py
> ===================================================================
> --- bindepend.py   (Revision 59)
> +++ bindepend.py   (Arbeitskopie)
> @@ -354,6 +354,12 @@
>      """Find the binary dependencies of PTH.

>          This implementation is for otool platforms"""
> +    # dyld searches these paths for framework libs
> +    # we ignore DYLD_FALLBACK_LIBRARY_PATH for now (man dyld)
> +    fwpaths = ['/Library/Frameworks', '/Network/Library/Frameworks', '/System/Library/Frameworks']
> +    for p in reversed(os.environ.get('DYLD_FRAMEWORK_PATH', '').split(':')):
> +        if p:
> +            fwpaths.insert(0, p)
>      rslt = []
>      for line in os.popen('otool -L "%s"' % pth).readlines():
>          m = re.search(r"\s+(.*?)\s+\(.*\)", line)
> @@ -363,6 +369,13 @@
>                  rel_path = lib.replace("@executable_path",".")
>                  rel_path = os.path.join(os.path.dirname(pth), rel_path)
>                  lib = os.path.abspath(rel_path)
> +            elif not os.path.isabs(lib):
> +                # lookup matching framework path, if relative pathname
> +                for p in fwpaths:
> +                    fwlib = os.path.join(p, lib)
> +                    if os.path.exists(fwlib):
> +                        lib = fwlib
> +                        break
>              if os.path.exists(lib):
>                  rslt.append(lib)
>              else:

> For your convenience, it's also attached.

> > > It looks like QT_PLUGIN_PATH is set correctly, and they also appear
> > > altogether, but those plugins bind with nearly all Qt libs in
> > > existence, and this dependancy is not handled correctly, yet.

> > This should be fixed wherever we fix the PyQt <-> Qt dependency, that is
> > with DYLD_LIBRARY_PATH (hopefully).

> Of course it won't, since you _still_ cannot fix a _missing_ library with
> playing environmental games ;-) The PyQt <-> Qt dependency is resolved with
> the attached patch.
> You will notice, when this starts to work, because the size of your app
> will grow considerably (as long as your app doesn't use QtNetwork, QtSql,
> QtXml, QtSvg, or Qt3Support, yet). They all get pulled with the full
> qt4_plugins support (see my list), but as you said before, they're handled
> as data files ATM, which is the root of the problem.