Question

I am attempting to build an almost static application because of portability concerns. I hope to be able to run the executable on several 64 bit linux distributions. I have been successful at statically linking Qt and building with statically linked libstdc++ and libgcc.

However, I have some 3rd party library concerns. I built Qt with -qt-zlib, but my end application is still dynamically linked with the system zlib. Specifically I configured with:

./configure -static -nomake demos -nomake examples -nomake tools -release -no-webkit -qt-zlib -no-gif -qt-libtiff -qt-libpng -qt-libmng -qt-libjpe

I removed all references linking to zlib in the application, assuming that the application would be able to link to the Qt’s statically built zlib. It almost appears to me that Qt is ignoring the -qt-zlib flag, and using the system library, which then my application also uses.

Furthermore, I had to install the libfontconfig-dev package so the font after building from source would not be horrific, but now Qt is also dynamically linking to it. There is a static library for libfontconfig that I tried to link to, as you can see, but because Qt is already linked to libfontconfig, the linker ignores it. Is there a way during the Qt build of being able to specify not to dynamically link to 3rd party libraries?

I do not want any of Qt’s dependencies to be statically linked, if possible. Right now I believe the application will work on at least Ubuntu 12.04, but other distributions very well may place some of the libraries in different places.

Snippet from my .pro file:

QT += core \
      gui \
      opengl
QMAKE_CXXFLAGS += -fpermissive
QMAKE_LFLAGS += -static-libgcc -static-libstdc++
CONFIG += static
TEMPLATE = app
LIBS += /usr/local/lib/libboost_thread.a \
        /usr/local/lib/libboost_program_options.a \
        /usr/lib/x86_64-linux-gnu/libfontconfig.a \
        /usr/lib/x86_64-linux-gnu/libGLU.a

Output from ldd:

linux-vdso.so.1 =>  (0x00007fff992b4000)
libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6 (0x00007f195ccbc000)
libICE.so.6 => /usr/lib/x86_64-linux-gnu/libICE.so.6 (0x00007f195caa2000)
**libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f195c86b000)**
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f195c5cf000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f195c3be000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f195c089000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f195be85000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f195bc7d000)
**libGL.so.1 => /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 (0x00007f195ba1c000)**
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f195b7ff000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f195b505000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f195b147000)
/lib64/ld-linux-x86-64.so.2 (0x00007f195ced9000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f195af42000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f195ad18000)
**libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f195ab00000)**
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f195a8e2000)
libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0 (0x00007f195a6bd000)
libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007f195a4b9000)
libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f195a2b3000)
libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f195a0b1000)
libxcb-glx.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0 (0x00007f1959e99000)
libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f1959c94000)
libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007f1959a89000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f1959885000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f195967f000)

Update:

I have since given up on this task as it does not seem doable. Since the developer has decided it would be okay to release the source, I will just port it with the standard ./configure, make, and make install.

Even if I was able to link these libraries statically, libc was of a different version from even Ubuntu 11. So far as I know, libc cannot be statically linked. It appears the best option is to build a package with GNU’s auto tools, but even that is a painful task.

Any hints or tips on how to go about using GNU’s tools to create the ./configure script for a Qt project?

Answer 1

Building a completely static executable that is portable is not easily done. There are a lot of technical concerns at why doing this is not really feasible, as I have learned. libc cannot be statically linked, so you must compile with an older version of libc for compatibility concerns.

The best solution for portability on linux platforms is releasing the source and using GNU’s Autotools to build a ./configure script. However, that task is not easily done with Qt projects.

Ultimately, I resorted to releasing the source with a basic installation script that will check that Qt is installed on the machine and use qmake to build the project. It’s not a great solution, but it works.

If you are not willing to release the source, build a semi-statically (with Qt and possibly a few other libraries) linked executable and an installer that verifies the libraries are in the correct locations and installs them if necessary.