[Development] Bug in macdeployqt?
Morten.Sorvig at theqtcompany.com
Fri Sep 18 13:32:09 CEST 2015
> 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:
> 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.
More information about the Development