Link all libraries into the executable (actually: make a deploy folder)

mrjj

Hi
You would have to compile your own version of Qt to allow static linking.
https://wiki.qt.io/Building_a_static_Qt_for_Windows_using_MinGW

It would be far less work just to make a deploy folder (with all dlls) and zip it and give zip to you friend.
http://www.tripleboot.org/?p=138

Then he would just click the exe and be happy.

Pippin

@mrjj Thanks for your reply!

Okay I sense your second solution is the right way to solve my problem. I'm using Ubuntu 15.10 and I believe he's using Windows as well as Ubuntu 14.04 LTS. Is your second link still accurate for my problem?

mrjj

I agree. it takes a little time to get all the dlls and
then u can reuse the folder for all other Qt programs.
Make sure NOT to mix debug version and release version of the dlls.
the debug has D in the name.

Update: Oh. first saw your question now:
On linux, same idea can work.
But u need a script to start the app then.
This script will export path (of your app) to the LDD so it can find the so files.

Also, often installing Qt on linux is very fast or it already has a version installed.
So the mention approach also work on linux even slightly more work.
YES: second link still good.
look for
Linux GCC 32-bit and 64-bit compilers:

asanka424

Agree with @mrjj. One thing you can use Dependency Walker and findout what libraries you need and include all of them in you deploy folder.

Also make sure you include Qt plugins as well. Dependecy Walker might not show these as dependencies. These are (incomplete list)

platforms
imageformats
iconengines
sqldrivers and etc.

asanka424

@mrjj if you are on linux you can use rpath and specify where to look for binaries, which is very handy. so you can distribute your application in a clean directory structure. you dont have to use a startup script

Pippin

I'm sorry but I'm a total newbie, I'd appreciate if somebody could walk me through it. First, how do I get to find the list of all the .so files I need (how do I know I need this one and not that one for instance) ?

mrjj

@asanka424
yeah I tried that once. Seems very handy.
Mostly used the script but rpath seems far more elegant.

mrjj

@Pippin
build you "exe" file
go to the folder in a shell
type
ldd ./yourprogram

and it lists all it needs.
But the http://www.tripleboot.org/?p=138 does list the barebone
SO files. so its a good start.
then u might need some boost so files.

asanka424

@mrjj Yes ldd is your friend in Ubuntu. Don't forget platforms folder in Qt plugins directory.

Pippin

Thanks for your replies.

This is what I get when I run ldd ./my_app

linux-vdso.so.1 =>  (0x00007ffd2c59c000)
libsfml-system.so.2.3 => /usr/local/lib/libsfml-system.so.2.3 (0x00007f754cf96000)
libsfml-network.so.2.3 => /usr/local/lib/libsfml-network.so.2.3 (0x00007f754cd78000)
libQt5Widgets.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 (0x00007f754c6f6000)
libQt5Gui.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 (0x00007f754c1bc000)
libQt5Core.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 (0x00007f754bd00000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f754bae1000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f754b75f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f754b457000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f754b23f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f754ae75000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f754ac6d000)
libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f754aa19000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f754a70a000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f754a3d0000)
libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f754a1a9000)
libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007f7549f4b000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f7549d31000)
libGL.so.1 => /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 (0x00007f7549a98000)
libicui18n.so.55 => /usr/lib/x86_64-linux-gnu/libicui18n.so.55 (0x00007f7549635000)
libicuuc.so.55 => /usr/lib/x86_64-linux-gnu/libicuuc.so.55 (0x00007f75492a1000)
libpcre16.so.3 => /usr/lib/x86_64-linux-gnu/libpcre16.so.3 (0x00007f754903d000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7548e39000)
/lib64/ld-linux-x86-64.so.2 (0x000056220c544000)
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f7548c30000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f75489c3000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f75487a2000)
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f75484fb000)
libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007f75482df000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f75480b6000)
libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0 (0x00007f7547e87000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f7547c75000)
libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007f7547a72000)
libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f754786b000)
libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f7547669000)
libxcb-glx.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0 (0x00007f7547450000)
libxcb-dri2.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0 (0x00007f754724a000)
libxcb-dri3.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0 (0x00007f7547047000)
libxcb-present.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-present.so.0 (0x00007f7546e44000)
libxcb-sync.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1 (0x00007f7546c3c000)
libxshmfence.so.1 => /usr/lib/x86_64-linux-gnu/libxshmfence.so.1 (0x00007f7546a39000)
libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f7546833000)
libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007f7546624000)
libicudata.so.55 => /usr/lib/x86_64-linux-gnu/libicudata.so.55 (0x00007f7544b6d000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f7544968000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f7544762000)

The very first file (linux-vdso.so.1) has no path, where can I find it?

@asanka424 said:

Also make sure you include Qt plugins as well. Dependecy Walker might not show these as dependencies. These are (incomplete list)

platforms
imageformats
iconengines
sqldrivers and etc.

How can I know which .so files in these folders are required, and which ones aren't?

Pippin

Status update: So I've managed to put all of the .so files that ldd listed in my project's directory. When I typed ldd ./my_app again, I could verify that every single .so file is found in my project's directory as expected.

Now, when I run ./my_app I get two different errors, depending on whether I run it on a computer that has all libraries installed, or on a computer that has nothing installed.

On Ubuntu 15.10 with everything installed:

./my_app: symbol lookup error: /home/lol/Documents/Coding/Union/libQt5Gui.so.5: undefined symbol: glGetString

On Ubuntu 15.10 with nothing installed:

This application failed to start because it could not find or load the Qt platform plugin "xcb".

So I must have skipped a few steps. Also, I'm not sure I understand why ldd never listed any kind of boost .so file. I must have to link the boost library at some point I suppose.

mrjj

Hi
Good work.
did u remember a subfolder called platforms
as mentioned here
http://www.tripleboot.org/?p=138

Im also a bit surprised that no boost is listed. Maybe u compile it in ?

Pippin

Okay but what about my first error?

./my_app: symbol lookup error: /home/lol/Documents/Coding/Union/libQt5Gui.so.5: undefined symbol: glGetString

It seems to indicate that something has not been linked, so I think it's the same problem as the boost problem I mentioned. How can I find out all of the .so files that I need and that ldd did not list? How would you guys solve this problem if it were yours?

Edit: Not sure if that helps, but additional information. I typed ldd -v ./my_app for further details and I found this (I filtered most of the output, it should be much longer than that):

	/home/lol/Documents/Coding/Union/./libQt5Core.so.5:
		ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2

	/home/lol/Documents/Coding/Union/./libpthread.so.0:
		ld-linux-x86-64.so.2 (GLIBC_2.2.5) => /lib64/ld-linux-x86-64.so.2
		ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
		ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2

	/home/lol/Documents/Coding/Union/./libstdc++.so.6:
		ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2

	/home/lol/Documents/Coding/Union/./libc.so.6:
		ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
		ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2

	/home/lol/Documents/Coding/Union/./libdl.so.2:
		ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2

For some reason, ld-linux-x86-64.so.2 (in my project directory) links to its other copy /lib64/ld-linux-x86-64.so.2 (not in my project directory) even though both files are identical. I literally copy/pasted it.

mrjj

Hi
I would take the SO files listed
http://www.tripleboot.org/?p=138
Please say you did read it.

and then try to deploy on clean linux.
if it wont start, i would use ldd to see which so it still needs on the clean machine.

Please note that not all dll that LDD lists are needed as some are part of linux so only Qt ones and libsfml
would be interesting.

some files like
/lib/x86_64-linux-gnu/libc.so.6
should already be in the linux

kshegunov

@Pippin
Don't copy system libraries at random, especially the linker, loader, the C runtime and the like! You need to extract all Qt's binaries and your external dependencies. Moreover, on linux one usually leaves the dependencies to the package manager instead of deploying copies of the libraries (by means of packaging one's apps/libraries). Consider, what happens if I try running your application (especially if you haven't set the rpath) on my machine, it's a recipe for trouble. If you're deploying for testing purposes I propose using LD_LIBRARY_PATH when starting the application.

This:

./my_app: symbol lookup error: /home/lol/Documents/Coding/Union/libQt5Gui.so.5: undefined symbol: glGetString

is a loader error and means that the open GL library is nowhere to be found. Make sure you have that installed on the machine.

Kind regards.

Pippin

@mrjj said:

http://www.tripleboot.org/?p=138
Please say you did read it.

Yes, I did read it.

But I think I'm failing to understand what you people want me to do. I've tried to follow the link you showed, and it caused problems, which I have submitted and am waiting for solutions. Especially, I would like to know how to find out the hidden .so files that my project needs.

@mrjj said:

and then try to deploy on clean linux.
if it wont start, i would use ldd to see which so it still needs on the clean machine.

I've already tried that, but shouldn't it first work on this machine before working on others?

@kshegunov said:

You need to extract all Qt's binaries and your external dependencies.

I'm sorry but as a newbie, I do not know how to do that. I am not using Qt Creator at all, I'm doing everything through the terminal. I use qmake, make and run the executable.

Also, I'm confused that the open GL library is nowhere to be found as I do link libGL.so.1, libglib-2.0.so.0, libglapi.so.0, libxcb-glx.so.0 and libglib-2.0.so.0. I'm looking forward to your next instructions.

kshegunov

@Pippin

I'm sorry but as a newbie, I do not know how to do that. I am not using Qt Creator at all, I'm doing everything through the terminal. I use qmake, make and run the executable.

I mean that you'd package them with your executable. From your ldd called on the application you get:

/home/lol/Documents/Coding/Union/./libQt5Core.so.5:
        ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2

which means, you'll need to have libQt5Core.so to run your application. However libstdc++.so is a system library and you shouldn't copy it along your application. Additionally, each of the *.so's you copy have dependencies of its own that should be met (meaning you have to copy them if needed as well).

When you start your application the loader (called also the dynamic linker on Linux) will read up the dependencies and start mapping the libraries to memory. Each of the loaded libraries' dependencies will be loaded as well. For this to happen the loader must know where to find the libraries. The singular path, provided a special rpath variable in the ELF header is not present, is a set of system directories (most commonly /lib, /usr/lib). There's a way to tell the loader where your libraries are located when starting your application with the LD_LIBRARY_PATH system variable, although for most cases this is discouraged. This somewhat lengthily describes what is done by the OS, and in fact is Qt-independent, it's just how Linux works.

Now, back to your original problem. After you copy all the Qt libraries you're using, and their dependencies (the link @mrjj provided is an excellent staring point), and after you make sure all the system libraries are installed on the sytem (like stdc++, libGL and so on) you can start your application. You do that like this:

>$ LD_LIBRARY_PATH=/path/to/libraries:$LD_LIBRARY_PATH ./executablename

/path/to/libraries is where the loader should search for the libraries you've copied, and executablename is the name of your program. If all the prerequisites are met (as described above) you should be able to see that your application runs.

Kind regards.

asanka424

if you have all your so files in same directory as your executable, it will find those libraries. Only things you want to copy is Qt related libaries. Other than files starting with libQt5 you will need

libicudata
libicui18n
libicuuc.so

Also platforms directory from qt plugings directory. For example
/opt/Qt/5.5.1/5.5/gcc_64/plugins.

kshegunov

@asanka424

if you have all your so files in same directory as your executable, it will find those libraries.

On Windows, yes, but not on Linux. You have to explicitly point the loader to the current working directory.

asanka424

@kshegunov I thought . is default added into rpath. Yes that is build chain specific thing and should not consider as a global thing.