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

kshegunov

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.

Pippin

@kshegunov Thanks for taking the time to break it down for me, I appreciate it. So I'll try to sort the .so file list I made earlier:

These files should be in my project directory:

platforms/libqxcb.so
libsfml-system.so.2.3
libsfml-network.so.2.3
libQt5Widgets.so.5
libQt5Gui.so.5
libQt5Core.so.5

As well as these files (because of the SFML libraries)

libfreetype.so.6
libX11.so.6
libxcb.so.1
libX11-xcb.so.1
libxcb-glx.so.0
libxcb-dri2.so.0
libxcb-dri3.so.0
libxcb-present.so.0
libxcb-sync.so.1
libGL.so.1
libpthread.so.0

As well as these files (because of the Qt libraries)

libicudata.so.55
libicui18n.so.55
libicuuc.so.55

And these files should not be included in my project directory:

libstdc++.so.6
libm.so.6
libgcc_s.so.1
libc.so.6
librt.so.1
libgobject-2.0.so.0
libglib-2.0.so.0
libgobject-2.0.so.0
libpng12.so.0
libharfbuzz.so.0
libz.so.1
libpcre16.so.3
libdl.so.2
libffi.so.6
libpcre.so.3
libgraphite2.so.3
libexpat.so.1
libglapi.so.0
libXext.so.6
libXdamage.so.1
libXfixes.so.3
libxshmfence.so.1
libXxf86vm.so.1
libdrm.so.2
libXau.so.6
libXdmcp.so.6

Did I get something wrong in any list? Anyway, I tried that and compiled my project successfully. When I run it however, I still get the old openGL message:

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

which I never had before I started to mess with .so files. I'm not sure how to determine which .so file is needed for glGetString.

kshegunov

@asanka424

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

Nope, by default rpath is not set.

@Pippin

Leave those to the system (don't copy them with your executable):

libfreetype - a fonts library
libX11* - X11 libraries
libxcb* - more X11 libraries
libGL - OpenGL library
libpthread - thread support

Copy libQt* (those that you need, and you seem to have done that) and libic* + the platform plugin (I also see it in your project folder).

I'm not sure how to determine which .so file is needed for glGetString.

This would be libGL.so, however if it's installed on your system it should be known to the loader. One thing that might be interfering with that would be some binary incompatibility - either a different compiler was used (unlikely to cause a problem) or a very different version of the library. Did you make sure you have libGL installed on your system?

Kind regards.

Pippin

Well I googled the issue, I added -lGL -lstdc++ -lc -lm -lglut -lGLU to LIBS in the .pro file but I still get the error. I really don't know what's happening here :S

libgl1-mesa-dev is already the newest version.

kshegunov

@Pippin
Could you run ld --verbose | grep SEARCH_DIR | tr -s ' ;' \\012 on the command line and paste what it returns? Additionally what does ldd libQt5Gui.so when you run it on your deployment folder's library?

hskoglund

Hi, just a guess, but you could also try changing the order of the -l files, now you have
-lGL -lstdc++ -lc -lm -lglut -lGLU
try change to
-lstdc++ -lc -lm -lglut -lGLU -lGL

asanka424

@Pippin is this a GUI or a command line app?