linuxdeployqt ldd Error

[ModelTech]

Thanks to some other posts, I was happy to find linuxdeplyqt. However, when I try to use it for my application, I get the error that ldd cannot find one of my libraries belonging to the application. The application works perfectly fine when building & running from Qt Creator but the output of ldd is as shown below.

linux-vdso.so.1 =>  (0x00007ffdf79cf000)
	libdfmcore.so.1 => not found
	libQt5Widgets.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 (0x00007f59fd664000)
	libQt5Gui.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 (0x00007f59fd11c000)
	libQt5Core.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 (0x00007f59fcc46000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f59fc8c4000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f59fc5ba000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f59fc3a4000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f59fbfda000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f59fbdbc000)
	libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f59fbb69000)
	libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f59fb858000)
	libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f59fb51d000)
	libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f59fb2f8000)
	libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007f59fb09a000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f59fae7f000)
	libGL.so.1 => /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 (0x00007f59fac0b000)
	libicui18n.so.55 => /usr/lib/x86_64-linux-gnu/libicui18n.so.55 (0x00007f59fa7a9000)
	libicuuc.so.55 => /usr/lib/x86_64-linux-gnu/libicuuc.so.55 (0x00007f59fa414000)
	libpcre16.so.3 => /usr/lib/x86_64-linux-gnu/libpcre16.so.3 (0x00007f59fa1ae000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f59f9faa000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f59f9da1000)
	/lib64/ld-linux-x86-64.so.2 (0x000056242837f000)
	libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f59f9b99000)
	libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f59f9928000)
	libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f59f9706000)
	libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f59f945c000)
	libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007f59f9236000)
	libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f59f900d000)
	libxcb-dri3.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0 (0x00007f59f8e0a000)
	libxcb-present.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-present.so.0 (0x00007f59f8c06000)
	libxcb-sync.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1 (0x00007f59f89ff000)
	libxshmfence.so.1 => /usr/lib/x86_64-linux-gnu/libxshmfence.so.1 (0x00007f59f87fc000)
	libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0 (0x00007f59f85cc000)
	libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f59f83ba000)
	libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007f59f81b7000)
	libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f59f7fb0000)
	libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f59f7dae000)
	libxcb-glx.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0 (0x00007f59f7b95000)
	libxcb-dri2.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0 (0x00007f59f798f000)
	libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f59f7789000)
	libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007f59f757a000)
	libicudata.so.55 => /usr/lib/x86_64-linux-gnu/libicudata.so.55 (0x00007f59f5ac2000)
	libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f59f58be000)
	libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f59f56b7000)

The issue is that libdfmcore.so.1 is a library created as part of my projects. The .pro file for the project creating this library is as follows. I can also not find any libdfmcore.so.1 on my disk (also not in /usr/lib) but the application runs perfectly from Qt Creator (and definately uses the code in this library). I can only find symbolic links to unknown. Any suggestions on what could be wrong here?

QT       += xml gui

greaterThan(QT_MAJOR_VERSION, 4): QT += widgets

TARGET = dfmcore
TEMPLATE = lib

DEFINES += DFMCORE_LIBRARY
DEFINES += QT_DEPRECATED_WARNINGS

SOURCES += \
    // Lot's of files

HEADERS += \
    // Lot's of files

unix {
    target.path = /usr/lib
    INSTALLS += target
}

[ModelTech]

Ok, got a little step further. I found the actual library file (it is called libdfmcore.so.1.0.0 and I copied that to usr/lib with the name libdfmcore.so.1. This makes ldd find it and also linuxdeployqt seems happy.

Question 1: how do I solve this properly. I mean, I expected the .pro file to state that it should install the library in /usr/lib but it clearly doesn't do so. How do I fix this?

Anyway, I get the next error:

ERROR: ldd outputLine: "/home/.../dfm: /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5: version `Qt_5' not found (required by /home/.../dfm)"

There is a symbolic link /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 that refers to a file /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.5.1 So, it seems that ldd does not go through the symbolic links to find the actual files.

Question 2: How to make ldd / linuxdeployqt find the actual library files through the symbolic links?

[hskoglund]

Hi, about that error message "version `Qt_5' not found" occurs when you have built your app using Qt 5.6 or later and the pre-installed Qt on your system (in /usr/lib/x86_64-linux-gnu/) is a version of Qt before 5.6 (you have 5.5.1).

The reason that error does not occur when you start your app from Qt Creator, is because Qt Creator patches the $PATH variable when in runs your app, so that the first entry points to your Qt installation (making ldd much happier).
For example, on my Ubuntu the $PATH normally is:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
but when Qt Creator launches a Qt app it's changed to:
/home/henry/Qt/5.9/gcc_64/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

Normally this shouldn't matter because a Qt app executable file gets an RPATH to your Qt installation anyway, on my Ubuntu it's:

chrpath myapp
RPATH=/home/henry/Qt/5.9/gcc_64/lib

however a successful run of linuxdeployqt on the app neuters that connection (a wise move which makes it possible to run the app on a PC without Qt installed) and changes it to:

chrpath myapp
RUNPATH=$ORIGIN/lib/

and this should suffice provided that the lib subdirectory has had all the necessary Qt files copied into it by linuxdeployqt.

[ModelTech]

@hskoglund

I am not completely sure whether I understand your remark. When I run chrpath for my app (dfm) I get:

chrpath dfm 
dfm: RUNPATH=$ORIGIN/lib/

But, I also get that $ORIGIN is empty and my $PATH seems to stay the same (Although echo $PATH does not show inclusion of the standard paths like /usr/local/sbin etc.). I have some settings in .bashrc to extend the standard $PATH using lines like:

export PATH=$PATH:/home/modeltech/bin

[hskoglund]

When you start the app, $ORIGIN is replaced with the current directory, where the app is. (Another approach is to add the current directory to the $PATH, but $ORIGIN is more convenient, no clobbering of $PATH is needed)

If chrpath shows $ORIGIN/lib/ that means you've run linuxdeployqt on your app, and that in the current directory there should be a subdirectory lib with all the needed Qt dlls (copied from the Qt installation by linuxdeployqt).

To make sure that pre-installed, ancient Qt doesn't rear its ugly head, you could edit your $PATH setting in .bashrc so that the path to your kosher Qt installation's lib directory comes first, on my Ubuntu it would be:

 export PATH=/home/henry/Qt/5.9.1/gcc_64/lib:$PATH

But beware, once version 5.10 of Qt is out, that PATH would be invalid, i.e. it's a short-term solution :-)

[jsulm]

@ModelTech $ORIGIN is a variable for the linker it tells it to take the directory where the executable file is located.
Please DO NOT CHANGE PATH for you app globally!
Why do you want to have that lib in /usr/lib?
"I expected the .pro file to state that it should install the library in /usr/lib" - why?
Usually linuxdeployqt creates a package (just a directory) containing all stuff needed to execute your app, there is no need to pollute the system directories.

To me it is not completely clear what the issue is: does linuxdeployqt not copy libdfmcore.so.1.0.0 into your package?

[ModelTech]

@jsulm

It can't even find libdfmcore.so.1.0.0 ...

And I just discovered that on my Mac, this libdfmcore library is also not copied to /usr/lib. You ask why I would want that. Well, I do not want that but if I do so, ldd & linuxdeplyqt can actually find it (plus the 'unix { ...}' part at the bottom in the .pro file originates from the template given by Qt Created when I created the project).

Note that both on linux and mac, I cannot run my app from a terminal, only from qt creator. This already suggests that there is something wrong, but I have no clue what...

[jsulm]

@ModelTech
Please read "Creating the Application Package" here: http://doc.qt.io/qt-5/linux-deployment.html
That ldd does not find the lib is normal (as the lib is not located in any directories where ldd is looking for libs). It will find it if you do the deployment as described in the link above. You will then have a shell script used to start your app. This script sets LD_LIBRARY_PATH variable before starting your app to tell linker where to look for your libs.

[ModelTech]

@jsulm

Now, there is something interesting. LD_LIBRARY_PATH is set in my .bashrc for compiling another tool. Removing that from my .bashrc makes linuxdeployqt find the libdfmcore (without cluttering the /usr/lib directory).

Nevertheless, linuxdeployqt still gives:

linuxdeployqt dfm
Not using FHS-like mode
app-binary: "/home/.../dfm/build/release/gui/dfm"
appDirPath: "/home/.../dfm/build/release/gui"
relativeBinPath: "dfm"
ERROR: ldd outputLine: "/home/.../dfm/build/release/gui/dfm: /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5: version `Qt_5' not found (required by /home/.../dfm/build/release/gui/dfm)"
ERROR: Please ensure that all libraries can be found by ldd. Aborting.

So, it seems that I have an issue with an old Qt version? What is the best approach to solve that?

[jsulm]

@ModelTech Looks like you need take care of this (https://github.com/probonopd/linuxdeployqt/blob/master/README.md):
"QMake configuration

Important: linuxdeployqt deploys the Qt instance that qmake on the $PATH points to, so make sure that it is the correct one. Verify that qmake finds the correct Qt instance like this before running the linuxdeployqt tool:

qmake -v

QMake version 3.0
Using Qt version 5.7.0 in /tmp/.mount_QtCreator-5.7.0-x86_64/5.7/gcc_64/lib

If this does not show the correct path to your Qt instance that you want to be bundled, then adjust your $PATH to find the correct qmake."

Probably linuxdeployqt takes the qmake delivered with your Linux distribution. You can adjust PATH before calling linuxdeployqt so it picks the correct qmake.

[ModelTech]

After undoing all the polluting of /usr/lib, I have tried most suggestions. Also qmake -v gives something totally different than what it should be.

Nevertheless, I did find a way that works but it is not very user-friendly. First of all, I have prepared the package with all the required libraries (including my own libdfmcore.so.1) in a lib subfolder. So, it looks like:

/dfm                              // Executable
/lib/libdfmcore.so.1              // My own lib to the executable
/lib/libQt5Gui.so.5               // Example of a required Qt library
/lib/...                          // More of them (all identified through linuxdeployqt)
/platforms/libqxcb.so             // Qt platform library
/plugins/libsdf3.so               // A plugin
/plugins/libbasictools.so         // Another plugin

With all this in place, run the application by executing the following commands from a terminal at the location of the executable:

LD_LIBRARY_PATH=$PWD/lib/
export LD_LIBRARY_PATH
./dfm

I tried to script the above, but for some reason that doesn't work. For now this approach is ok, but suggestions for a more user-friendly solution are appreciated.

[jsulm]

@ModelTech Did you actually read the links I provided (http://doc.qt.io/qt-5/linux-deployment.html and https://github.com/probonopd/linuxdeployqt/blob/master/README.md)? As I said you're using wrong qmake, do it like described in my previous post: "If this does not show the correct path to your Qt instance that you want to be bundled, then adjust your $PATH to find the correct qmake."
"I tried to script the above, but for some reason that doesn't work" - what does not work?
In the link above, if you read it, you will find ready made script to start your app, all you have to do is to copy this script into a text file, name this file NAME_OF_YOUR_APP.sh and put it in the same directory where NAME_OF_YOUR_APP is.

[ModelTech]

Calling qmake from the command line does not work in my environment. Changing the $PATH does not help in any way. I tried hard.

I solved the scripting problem by studying one of the referred pages in more details, but it did't work as it was described there. I did however give me the right inspiration. Thanks :)

Anyway, on my Mac, I basically experience the same problem! It all has clearly to do with the fact that I use a library that I build myself (as a subproject for the whole project) and which is not accessible from /usr/lib. I have tried to put this library file at various places in (subfolders of) the Content folder of the application bundle. I also tried to alter the qt.conf file using the Library and LibraryExecutables fields. None of this worked: macdeployqt can't find the library file and it really wants it at /usr/lib. The only thing that I get to work is to put the .dylib file in the MacOs subfolder and run the application by calling the executable from within the MacOs subfolder from the command line. Not the solution that a typical Mac user will like...

[SGaist]

Hi,

Take a look at the Linking the application to Qt as a framework chapter of the deployment documentation. It shows how to use macOS tools in order to deploy an application.

You can use them in addition to macdeployqt when you have unusual stuff happening.