<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 6, 2014 at 4:20 PM, Darren Dale <span dir="ltr"><<a href="mailto:dsdale24@gmail.com" target="_blank">dsdale24@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div class="">On Mon, Aug 4, 2014 at 11:59 PM, Thiago Macieira <span dir="ltr"><<a href="mailto:thiago.macieira@intel.com" target="_blank">thiago.macieira@intel.com</a>></span> wrote:<br>
</div><div class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div>On Monday 04 August 2014 09:47:55 Darren Dale wrote:<br>

> I spent a good part of the weekend looking for information on the web. I'm<br>
> not certain I understand the problem, but am certain there must be a<br>
> solution, since the Qt installer for windows can install to an arbitrary<br>
> location.<br>
<br>
</div>It does that by binary-patching QtCore and qmake.<br>
<br>
Does your installation do that?<br>
<div><br>
> I found a short discussion at <a href="http://stackoverflow.com/a/17640221" target="_blank">http://stackoverflow.com/a/17640221</a><br>
> , talking about how qmake, Qt5Core, and a few other files need to be<br>
> patched, but did not understand exactly what needs to be patched, and how.<br>
> (Please excuse me for not understanding the c++ code that was posted.) Is<br>
> there any documentation on how to do this?<br>
<br>
</div>Looks like you didn't.<br>
<br>
Run strings on those files and you'll see the build paths. You need to replace<br>
those paths in the binaries and remove the qt.conf file.<br></blockquote></div><div><br><div class="">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!<br><br></div></div><div>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. </div>
</div></div></div></blockquote><div><br></div><div>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:</div>
<div><br></div><div>---</div><div><div>qtdetail.app/Contents/MacOS/qtdetail</div><div>dyld: Library not loaded: libQt5Core.5.dylib</div><div>  Referenced from: /Users/darren/Downloads/PyQt-gpl-5.3.1/qtdetail.app/Contents/MacOS/qtdetail</div>
<div>  Reason: image not found</div><div>Error: qtdetail.app/Contents/MacOS/qtdetail failed to create qtdetail.out. Make</div><div>sure your Qt installation is correct.</div></div><div>---</div><div><br></div><div>If I check the output of `$ otool -L qtdetail.app/Contents/MacOS/qtdetail`:</div>
<div><br></div><div>---</div><div>qtdetail.app/Contents/MacOS/qtdetail:</div><div><span class="" style="white-space:pre">     </span>libQt5Core.5.dylib (compatibility version 5.3.0, current version 5.3.1)</div><div><span class="" style="white-space:pre">    </span>/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 60.0.0)</div>
<div><span class="" style="white-space:pre">    </span>/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)</div><div>---</div><div><br></div><div>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:</div>
<div><br></div><div>---</div><div>libQt5Core.so.5 => /home/darren/envs/qt5/lib/libQt5Core.so.5</div><div>---</div><div><br></div><div>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:</div>
<div><br></div><div>---</div><div>$ env -i PATH=/usr/bin xcodebuild -version</div><div>Xcode 5.1.1</div><div>Build version 5B1008</div><div><br></div><div>$ env -i DYLD_LIBRARY_PATH=/Users/darren/anaconda/envs/qt5/lib PATH=/usr/bin xcodebuild -version</div>
<div>dyld: Symbol not found: _sqlite3_intarray_bind</div><div>  Referenced from: /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData</div><div>  Expected in: /Users/darren/anaconda/envs/qt5/lib/libsqlite3.dylib</div>
<div> in /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData</div><div>Trace/BPT trap: 5</div><div><br></div><div>$ env -i DYLD_LIBRARY_PATH=/Users/darren/anaconda/envs/qt5/lib /Users/darren/anaconda/envs/_build/bin/qmake-qt5 -o <a href="http://qtdetail.mk">qtdetail.mk</a> <a href="http://qtdetail.pro">qtdetail.pro</a></div>
<div><div>dyld: Symbol not found: _sqlite3_intarray_bind</div><div>  Referenced from: /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData</div><div>  Expected in: /Users/darren/anaconda/envs/_build/lib/libsqlite3.dylib</div>
<div> in /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData</div><div>sh: line 1:  2189 Trace/BPT trap: 5       /usr/bin/xcodebuild -version</div><div>Project ERROR: Could not resolve Xcode version.</div></div>
<div><br></div><div>$ unset DYLD_LIBRARY_PATH</div><div>$ /Users/darren/anaconda/envs/_build/bin/qmake-qt5 -o <a href="http://qtdetail.mk">qtdetail.mk</a> <a href="http://qtdetail.pro">qtdetail.pro</a></div><div>Info: creating stash file /Users/darren/Downloads/PyQt-gpl-5.3.1/.qmake.stash</div>
<div>---<br></div><div><br></div><div>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.</div>
<div><br></div><div>Thanks,</div><div>Darren</div><div><br></div></div></div></div>