[Development] linuxdeployqt

[Henry Skoglund]

On 2016-09-21 17:02, Thiago Macieira wrote:
> On quarta-feira, 21 de setembro de 2016 11:06:59 PDT Konrad Rosenbaum wrote:
>> RPath may be a bit tricky: normally Qt compiles it's lib path into RPath,
>> but with a deploy script you do not want that RPath anymore, instead you'd
>> want to change it to $ORIGIN (literally, not the value of a variable).
>
> Don't change. If you want $ORIGIN, you tell the linker you want it.
>
> Also, RPATH is tricky, but for another reason:
>
> - If DT_RUNPATH is present, check $LD_LIBRARY_PATH first and ignore DT_RPATH
> - if only DT_RPATH is present, check it before $LD_LIBRARY_PATH
>

About paths, if we want linuxdeployqt to harmonize with windeployqt's 
behavior: since last year windeployqt unpatches (i.e. neuters) Qt's 
installation path in Qt5Core.dll, so that for example my Qt5Core.dll is 
patched from "qt_prfxpath=C:\Qt\5.7\msvc2013\" to "qt_prfxpath=.". This 
severes any pathological connections my app would have with my Qt 
installation (and shuts a small but possible backdoor).

(And, when I copy my app to a vanilla PC, I can either place the 
platforms subdirectory next to my .exe file, or I want to get fancy, 
copy the whole plugins tree and place it next my .exe file. Either works 
fine for loading qwindows.dll.)

So perhaps linuxdeployt could do the same, i.e. neuter the path to my Qt 
installation (e.g. change "prfxpath=/home/henry/Qt/5.7/gcc_64" to 
"prfxpath=." in libQt5Core.so.5.7.0?


In theory you could apply the same reasoning to RPATH, why let Qt's 
installation path remain artifacted in the .elf file? Perhaps $ORIGIN is 
a nicer default. (windeployqt does not do this step, as on Windows 
$ORIGIN is the "standard" anyway).

Rgrds Henry