Я пытаюсь создать почти статическое приложение из-за проблем с переносимостью. Я надеюсь, что смогу запустить исполняемый файл на нескольких 64-битных дистрибутивах Linux. Мне удавалось статически связывать Qt и строить со статически связанными libstdC++ и libgcc.Static Qt 4.8.1 Build on Ubuntu 12.04
Однако у меня есть проблемы со сторонней библиотекой. Я построил Qt с -qt-zlib, но мое конечное приложение по-прежнему динамически связано с системой zlib. В частности, я настроен:
./configure -static -nomake demos -nomake examples -nomake tools -release -no-webkit -qt-zlib -no-gif -qt-libtiff -qt-libpng -qt-libmng -qt-libjpe
я удалил все ссылки, ссылающиеся на ZLIB в заявке, при условии, что приложение будет иметь возможность связать статический построенной Zlib в Qt. Мне кажется, что Qt игнорирует флаг -qt-zlib и использует системную библиотеку, которую также использует мое приложение.
Кроме того, мне пришлось установить пакет libfontconfig-dev, поэтому шрифт после создания из источника не был бы ужасным, но теперь Qt также динамически связывается с ним. Существует статическая библиотека для libfontconfig, к которой я пытался подключиться, как вы можете видеть, но поскольку Qt уже связан с libfontconfig, компоновщик игнорирует его. Есть ли способ во время сборки Qt иметь возможность указывать не динамически ссылаться на сторонние библиотеки?
Я не хочу, чтобы какая-либо из зависимостей Qt была статически связана, если это возможно. Сейчас я считаю, что приложение будет работать, по крайней мере, Ubuntu 12.04, но другие дистрибутивы очень хорошо могут размещать некоторые библиотеки в разных местах.
Отрывок из моего .pro файла:
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
Выход из 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:
С тех пор я отказался от этой задачи, как это не кажется выполнимо. Поскольку разработчик решил, что было бы нормально выпустить источник, я просто портирую его со стандартным ./configure, make и make install.
Даже если бы мне удалось связать эти библиотеки статически, libc был другой версии даже от Ubuntu 11. Насколько я знаю, libc не может быть статически связан. Похоже, лучший вариант - создать пакет с автоматическими инструментами GNU, но даже это очень тяжелая задача.
Любые подсказки или советы по использованию инструментов GNU для создания сценария ./configure для проекта Qt?