<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Sep 18, 2015 at 1:32 PM, Sorvig Morten <span dir="ltr"><<a href="mailto:Morten.Sorvig@theqtcompany.com" target="_blank">Morten.Sorvig@theqtcompany.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 17 Sep 2015, at 19:15, Dean Floyd <<a href="mailto:dean.floyd.lkml@gmail.com">dean.floyd.lkml@gmail.com</a>> wrote:<br>
><br>
> Dear all,<br>
><br>
> We have a project where we weak link our app against the Wacom framework which on MacOSX by default gets installed in:<br>
><br>
> /Library/Frameworks/WacomMultiTouch.framework<br>
><br>
> otool -L returns the following line for the Wacom link:<br>
><br>
> @rpath/WacomMultiTouch.framework/Versions/A/WacomMultiTouch (compatibility version 1.1.0, current version 1.1.2)<br>
><br>
> When running macdeployqt we get the following error:<br>
><br>
> ERROR: Cannot resolve rpath "WacomMultiTouch.framework/Versions/A/WacomMultiTouch (compatibility version 1.1.0, current version 1.1.2)"<br>
> ERROR:  using QSet("/Applications/Qt/5.5/clang_64/lib", "/Library/Frameworks")<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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?<br>
<br>
</span>Yes, in general the main focus for macdeployqt has been deployment of the Qt frameworks.<br>
<br>
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.<br></blockquote><div><br></div><div>Thank you for the confirmation. Looking at the functions names, I also noticed that macdeployqt is dedicated to Qt-only libraries. I hope a support for non-qt libraries will be included in the future. In our case just ignoring the error was sufficient to fix the problem. It turns out the Wacom otool line in the executable needed no change at all. Our app contains to work as expected even with this "error" from macdeployqt.</div><div><br></div><div>Thanks,</div><div><br></div><div>Dean Floyd </div></div></div></div>