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).
Development mailing list