[Interest] question about relocating Qt library installation

[Darren Dale]

On Wed, Aug 6, 2014 at 4:20 PM, Darren Dale <dsdale24 at gmail.com> wrote:

> On Mon, Aug 4, 2014 at 11:59 PM, Thiago Macieira <
> thiago.macieira at intel.com> wrote:
>
>> On Monday 04 August 2014 09:47:55 Darren Dale wrote:
>> > I spent a good part of the weekend looking for information on the web.
>> I'm
>> > not certain I understand the problem, but am certain there must be a
>> > solution, since the Qt installer for windows can install to an arbitrary
>> > location.
>>
>> It does that by binary-patching QtCore and qmake.
>>
>> Does your installation do that?
>>
>> > I found a short discussion at http://stackoverflow.com/a/17640221
>> > , talking about how qmake, Qt5Core, and a few other files need to be
>> > patched, but did not understand exactly what needs to be patched, and
>> how.
>> > (Please excuse me for not understanding the c++ code that was posted.)
>> Is
>> > there any documentation on how to do this?
>>
>> Looks like you didn't.
>>
>> Run strings on those files and you'll see the build paths. You need to
>> replace
>> those paths in the binaries and remove the qt.conf file.
>>
>
> Thank you very much for your help. conda does have some support for
> specifying binary files that need patching like this, but I had not tried
> patching files *and* removing qt.conf. This worked, thank you!
>
> Is there anything special about building a -no-framework qt5 on OS X
> (10.9)? Using the same recipe as I did for linux, but with -no-framework, I
> can build (though not in parallel), and qmake -query looks right. But I get
> a segfault if I try to run designer.
>

I just wanted to follow up, I was successful in building a relocateable
-no-framework Qt package on OS X. However, another question arose while
building PyQt5. The PyQt5 configure script uses qmake to compile a simple
program called qtdetail to determine the details of the Qt installation
with which qmake is associated. This works fine on Linux, but fails on OS
X. The output of `qmake -query` is correct for my relocated library on OS
X, and qtdetail compiles fine, but it doesn't get installed anywhere and
won't run in place:

---
qtdetail.app/Contents/MacOS/qtdetail
dyld: Library not loaded: libQt5Core.5.dylib
  Referenced from:
/Users/darren/Downloads/PyQt-gpl-5.3.1/qtdetail.app/Contents/MacOS/qtdetail
  Reason: image not found
Error: qtdetail.app/Contents/MacOS/qtdetail failed to create qtdetail.out.
Make
sure your Qt installation is correct.
---

If I check the output of `$ otool -L qtdetail.app/Contents/MacOS/qtdetail`:

---
qtdetail.app/Contents/MacOS/qtdetail:
libQt5Core.5.dylib (compatibility version 5.3.0, current version 5.3.1)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version
60.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
1197.1.1)
---

libQt5Core.5.dylib doesn't include the path information necessary to find
the library. This seems like a problem to me. On linux, `ldd qtdetail`
indicates:

---
libQt5Core.so.5 => /home/darren/envs/qt5/lib/libQt5Core.so.5
---

On OS X, The build has produced a binary that assumes Qt can be found in
the OS's default library search path. I know it is common to use a
framework on OS X, but I don't think this is an option in my case. Is there
an option I can pass to qmake to instruct the build process to include the
library path information in the binary? Or more likely, an option I can
pass when configuring the Qt build? One might suggest using
DYLD_LIBRARY_PATH to point to the location of my Qt installation, in fact
this is what we have done to build PyQt4 conda packages for OS X in the
past, but it isn't necessary on linux, and it appears to be incompatible
newer versions of xcode, which in turn breaks qmake:

---
$ env -i PATH=/usr/bin xcodebuild -version
Xcode 5.1.1
Build version 5B1008

$ env -i DYLD_LIBRARY_PATH=/Users/darren/anaconda/envs/qt5/lib
PATH=/usr/bin xcodebuild -version
dyld: Symbol not found: _sqlite3_intarray_bind
  Referenced from:
/System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
  Expected in: /Users/darren/anaconda/envs/qt5/lib/libsqlite3.dylib
 in /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
Trace/BPT trap: 5

$ env -i DYLD_LIBRARY_PATH=/Users/darren/anaconda/envs/qt5/lib
/Users/darren/anaconda/envs/_build/bin/qmake-qt5 -o qtdetail.mk qtdetail.pro
dyld: Symbol not found: _sqlite3_intarray_bind
  Referenced from:
/System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
  Expected in: /Users/darren/anaconda/envs/_build/lib/libsqlite3.dylib
 in /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
sh: line 1:  2189 Trace/BPT trap: 5       /usr/bin/xcodebuild -version
Project ERROR: Could not resolve Xcode version.

$ unset DYLD_LIBRARY_PATH
$ /Users/darren/anaconda/envs/_build/bin/qmake-qt5 -o qtdetail.mk
qtdetail.pro
Info: creating stash file
/Users/darren/Downloads/PyQt-gpl-5.3.1/.qmake.stash
---

I found a workaround, for now, using DYLD_FALLBACK_LIBRARY_PATH instead of
DYLD_LIBRARY_PATH. But it seems like a better solution would be an option
to build binaries on OS X similar to the way they are done on Linux, with
the full (absolute or relative) path to the linked libraries. Then the
binaries could be used in place, and I can use Mach-O to change the paths
when files are installed to their final location.

Thanks,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20140808/ece2da6d/attachment.html>