On Fri, Aug 8, 2014 at 10:13 AM, Darren Dale <dsdal...@gmail.com> wrote:
> 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. > I found a bug related bug report: https://bugreports.qt-project.org/browse/QTBUG-31814
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
