[Development] Bug in macdeployqt?
Dean Floyd
dean.floyd.lkml at gmail.com
Fri Sep 18 19:00:50 CEST 2015
On Fri, Sep 18, 2015 at 1:32 PM, Sorvig Morten <
Morten.Sorvig at theqtcompany.com> wrote:
>
> > 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.
>
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.
Thanks,
Dean Floyd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150918/d9e826ea/attachment.html>
More information about the Development
mailing list