[Development] Bug in macdeployqt?

[Sorvig Morten]

> On 17 Sep 2015, at 19:15, Dean Floyd <dean.floyd.lkml at gmail.com> wrote:
> 
> Dear all,
> 
> We have a project where we weak link our app against the Wacom framework which on MacOSX by default gets installed in:
> 
> /Library/Frameworks/WacomMultiTouch.framework
> 
> otool -L returns the following line for the Wacom link:
> 
> @rpath/WacomMultiTouch.framework/Versions/A/WacomMultiTouch (compatibility version 1.1.0, current version 1.1.2)
> 
> When running macdeployqt we get the following error:
> 
> ERROR: Cannot resolve rpath "WacomMultiTouch.framework/Versions/A/WacomMultiTouch (compatibility version 1.1.0, current version 1.1.2)"
> ERROR:  using QSet("/Applications/Qt/5.5/clang_64/lib", "/Library/Frameworks")
> 
> I took a look at the macdeployqt's source code and it looks like there's something wrong at parseOtoolLibararyLine() in qttools/src/macdeployqt/shared.cpp.
> 
> It looks like in line 238 a "lib/" is put after the substitution of @rpath, which causes the Wacom framework not to be resolved properly. A comment in line 222 suggests that macdeployqt assumes that everything which of the QtPath state is a Qt library. In our case Wacom is not a Qt library so the additional "/lib" insertation breaks our build.
> 
> There are other libraries in /Library/Frameworks which are not Qt libraries which may be potential linked against a Qt application, and as far as I can see, this is not account for in macdeployqt. Could somebody please confirm this? 

Yes, in general the main focus for macdeployqt has been deployment of the Qt frameworks. 

I do think deploying non-Qt libraries with macdeployqt is a valid use case, so there’s a possibility we can make this work better in the future.

Morten