LD_LIBRARY_PATH and QT

[pkj]

RPATH is set by qmake makefile generation if the qt is not in the default library. For anyone working on linux with a newer version of qt will probably have qt on a /opt/ folder or similar non default folder. Once rpath is set, the ld_library_path thing doesn't work as rpath has a higher priority over ld_library_path. Refer https://blog.qt.digia.com/blog/2011/...h-and-runpath/
In such cases we need to remove the rpath by PatchElf or chrpath. Chrpath only works for 32 bit executables. Or the flags as op has entered is an option. Or modify the generated makefile by hand.
Once rpath dependencies go, the shell script mentioned in qt documentation works as ld_library_path gets higher precedence.
Am I wrong in my understanding somewhere. Guys??

[wysota]

This is true only if you wish to override one (existing in the system) version of Qt library with another one, assuming your application was built with RPATH pointing to the location of the wrong library.

[pkj]

This is true only if you wish to override one (existing in the system) version of Qt library with another one, assuming your application was built with RPATH pointing to the location of the wrong library.

Generally in at-office work environment, qt comes pre-installed in the distribution (RHEL) for example so that kde can use it. The new qt5 versions i download, are added in /opt/ or /home/ folders. So linking against these newer qt version and using qmake to generate makefiles causes the addition of a DT_RPATH variable in the executable/library. Is there a way to tell qmake to not do so. Does adding LD_LIBRARY_PATH in the runtime settings avoid this? I tried a few combinations, but had to finally remove it -rpath manually from the generated makefile. This I have to do everytime I build the executable/library or use a nix-patcher.
Is there any way to avoid all this and tell the qmake about not adding -rpath so that the shell which exports the new ld_library_path works as expected and ld loads the shared libraries of my choice?

[wysota]

Your system's Qt is Qt4 or Qt5? If Qt4 then I don't see what problem you are having -- you cannot replace Qt4 libs with Qt5 or vice versa.

[pkj]

system is rhel6. It contains qt 4 libraries. If i replace the libraries, then kde and qt dependent application will break as qt 4 and 5 are not binary compatible. Or so I think.

[wysota]

Qt5 apps links explicitly against Qt5 libraries (libQt5Core.so.5). There is no way you could mix Qt4 and Qt5 libs.