[Development] Qt 4.x and Qt 5 frameworks should use @rpath (QTBUG-31814)
Thiago Macieira
thiago.macieira at intel.com
Thu Aug 7 16:22:14 CEST 2014
On Thursday 07 August 2014 14:55:06 Adam Strzelecki wrote:
> The changes for qtbase are there:
>
> https://codereview.qt-project.org/91669
> https://codereview.qt-project.org/91670
> https://codereview.qt-project.org/91671
> https://codereview.qt-project.org/91672
> https://codereview.qt-project.org/91673
> https://codereview.qt-project.org/91674
> https://codereview.qt-project.org/91675
> https://codereview.qt-project.org/91676
>
> This makes Qt SDK build:
> (1) completely relocatable once installed
> (2) all tools and examples refer frameworks relatively
> (3) there is no hardcoded SDK in any framework or tool (except qmake which
> keep SDK prefix)
>
> Next steps:
> (1) changes to macdeployqt (removing absolute rpath & rewrite)
> (2) remove rewriting in installer-framework
Please don't remove the rewriting of qmake itself.
> FYI since installer rewrites absolute paths in frameworks, and there a none
> now this shouldn't have impact on Mac SDK installer itself.
Nice work!
How does a launched application find the Qt frameworks that were installed by
the SDK? And how do those frameworks find the plugins?
I mean, if I compile an application, the path to the frameworks is set with
the -F switch, which qmake knows as it's hardcoded. But how does the dyld know
the path when the application is launched? Doesn't DYLD_LIBRARY_PATH and
DYLD_FRAMEWORK_PATH need to be set? Is the Creator modification one of those
changes?
Also, how does QtCore find the plugins on behalf of every library? For example,
when QtGui requests the cocoa platform plugin, what is the search logic?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Development
mailing list