LD_LIBRARY_PATH failing while trying to run Qt app

Question

I want to run a Qt 5 based application usind dynamic libraries on Linux. In summary, a script will copy the executable and other relevant files, including all required .so inside a lib folder, to the desired destination and a script calling gksudo will work as caller to the app.

Till now everything works fine till I call the executable script: the app doesn't run. When I ask to run with sudo, it tells me that a library (Qt5SerialPort...) is missing. Running ldd over the actual executable I discover that the app is getting the required libs not from within the lib folder, but some apparent hard-coded paths.

I tried to solve this by using qt.conf but got no success. As note here, it would seem qt.conf isn't actually supposed to work this way. Consulting the Qt documentation, I decided to use LD_LIBRARY_PATH to tell the linker where to find the libs since I was already using a script to run the app anyway. So the final, summarized script code is

#!/bin/sh
LD_LIBRARY_PATH=lib/
export LD_LIBRARY_PATH
sudo ldconfig #sometimes  sudo /sbin/ldconfig -v
gksudo "$INSPATH/myApp" #or sudo instead

Problem is that it is still not working. When I call echo $LD_LIBRARY_PATH, I can see the variable was properly edited, but when I call the run line (with sudo), it keeps telling me that lib wasn't found.

What am I missing?

Answer 1

sudo doesn't pass LD_LIBRARY_PATH:

$ LD_LIBRARY_PATH=lib/
$ export LD_LIBRARY_PATH
$ env | grep LD_LIBRARY_PATH
LD_LIBRARY_PATH=lib/
$ sudo env | grep LD_LIBRARY_PATH

You can set it for the command run as root:

$ sudo env LD_LIBRARY_PATH=/lib env | grep LD_LIBRARY_PATH
SUDO_COMMAND=/usr/bin/env LD_LIBRARY_PATH=/lib env
LD_LIBRARY_PATH=/lib

You'll want something like

sudo env LD_LIBRARY_PATH=/lib "$INSPATH/myApp"

As always, be careful with sudo!

Answer 2

This is a real Linux problem. The best solution is to explicitly set the library locations in the executable, but that is not that simple.

Linux applications can be started when a so-called desktop file is created. All major software companies, like Google, create a desktop files of their product on the user's desktop or in the menu through an install script. The problem is that the desktop file needs the hard-coded location of the application. That means during installing this location must be interrogated and set in the desktop file. In addition the desktop file is a text file in which LD_LIBRARY_PATH cannot be set.

There is a workaround it. It does not win a beauty contest but it works. One can always start an application through a script and this script can set LD_LIBRAREY_PATH before running the application. But users might not like running/clicking an "application.sh" script. They expect to run it by double clicking on the application file. We solve this in the following way: when the script is executed we know the file location of the application. So we let the script first generate the desktop file and then execute the application. The desktop file executes the script. But as you can set the name and icon of the desktop file this becomes transparent to the user.

Final result is that the user has to click the shell script once and from then on a real application shortcut file can be clicked.

For details see.