1

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?

Momergil
  • 2,213
  • 5
  • 29
  • 59

2 Answers2

5

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!

Toby Speight
  • 27,591
  • 48
  • 66
  • 103
  • thanks for the tip, but although it would seem that the lib is now being found (using the last line of code), now it's telling that another lib is missing. Using `ldd` I'm able to notice it's one of the "default" libs that comes with Ubuntu inside `/usr/lib` and that was being previously found. How can I add both previous `/usr/lib` a.w.a. `user/local/lib` to `LD_LIBRARY_PATH` using your suggested method? – Momergil Dec 08 '15 at 17:06
  • @Momergil, `LD_LIBRARY_PATH` is an ordinary colon-separated path list, so you can `LD_LIBRARY_PATH=/lib:/usr/local/lib` to do that. – Toby Speight Dec 08 '15 at 17:18
  • well I though so and tested that and it didn't work, that's why I asked. But nevermind, I found it was my mistake: actually the linker is complaining because it can't find lib `libicui18n.so.**53**` while `ldd` reports the usage of `libicui18n.so.**52**` only. I tried to find this version 53 in the machine, but nothing was found, nor in the machine where the .so inside `lib` came from - and I can run the app inside Qt Creator in both machines! Any suggestions how may I go around this strange thing (as well as why `ldd` is asking for v. 52 and later v. 53 is asked? – Momergil Dec 08 '15 at 18:31
  • Best make that a question of its own - I don't think it will get enough eyeballs here in the comments... – Toby Speight Dec 08 '15 at 18:43
  • Well I managed to understand what is happening: the libs I put inside `/lib` are from Qt version 5.4 and they are linked to the version 53 of `libicui18n`, which I wasn't including with the Qt .so files. So the system was using version 5.4 for the Qt lib files but was using the `libicui18n` version of the Qt installed in that machine, namely 5.3 which is linked to version 52. Problem solved by putting all "extra" libs inside `/lib`. – Momergil Dec 09 '15 at 12:28
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.

adlag
  • 1,016
  • 9
  • 19