On Wed, Aug 6, 2014 at 4:20 PM, Darren Dale <dsdal...@gmail.com> wrote:
> On Mon, Aug 4, 2014 at 11:59 PM, Thiago Macieira < > thiago.macie...@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
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
