[Interest] question about relocating Qt library installation

[Darren Dale]

On Fri, Aug 8, 2014 at 10:13 AM, Darren Dale <dsdale24 at gmail.com> wrote:

> 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.
>

I found a bug related bug report:
https://bugreports.qt-project.org/browse/QTBUG-31814
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20140808/0225c30f/attachment.html>