[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