> On 17 Sep 2015, at 19:15, Dean Floyd <[email protected]> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
