1

移植性の懸念から、ほとんど静的なアプリケーションを構築しようとしています。いくつかの64ビットLinuxディストリビューションで実行可能ファイルを実行できることを望んでいます。Qtを静的にリンクし、静的にリンクされたlibstdc++とlibgccを使用してビルドすることに成功しました。

ただし、サードパーティのライブラリに関する懸念がいくつかあります。-qt-zlibを使用してQtをビルドしましたが、エンドアプリケーションはシステムzlibと動的にリンクされています。具体的には、次のように構成しました。

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

アプリケーションがQtの静的に構築されたzlibにリンクできると想定して、アプリケーション内のzlibにリンクしているすべての参照を削除しました。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)

アップデート:

それが実行可能ではないように思われるので、私はそれ以来このタスクをあきらめました。開発者はソースをリリースしても大丈夫だと判断したので、標準の./configure、make、makeinstallを使用して移植します。

これらのライブラリを静的にリンクできたとしても、libcはUbuntu 11とは異なるバージョンでした。私が知る限り、libcを静的にリンクすることはできません。GNUの自動ツールを使用してパッケージを構築するのが最善のオプションのようですが、それでも面倒な作業です。

GNUのツールを使用してQtプロジェクトの./configureスクリプトを作成する方法に関するヒントはありますか?

4

2 に答える 2

1

移植可能な完全に静的な実行可能ファイルを作成するのは簡単ではありません。私が学んだように、なぜこれを行うことが実際に実行可能でないのかについては、多くの技術的な懸念があります。libcは静的にリンクできないため、互換性の問題のために古いバージョンのlibcでコンパイルする必要があります。

Linuxプラットフォームでの移植性のための最良の解決策は、ソースをリリースし、GNUのAutotoolsを使用して./configureスクリプトを作成することです。ただし、そのタスクはQtプロジェクトでは簡単に実行できません。

最終的には、Qtがマシンにインストールされていることを確認し、qmakeを使用してプロジェクトをビルドする基本的なインストールスクリプトを使用してソースをリリースすることにしました。これは優れたソリューションではありませんが、機能します。

ソースをリリースしたくない場合は、半静的に(Qtおよび場合によっては他のいくつかのライブラリを使用して)リンクされた実行可能ファイルと、ライブラリが正しい場所にあることを確認し、必要に応じてインストールするインストーラーをビルドします。

于 2012-06-13T19:54:19.773 に答える
0

私が推測できるなら..

少し前に、私はいくつかのLinuxベースのOSで静的にリンクされたアプリケーションを作成し、すべての静的ライブラリを含める必要がありました。私も3partyを使用したいと思います。しかし、Qtモジュールでは、それは不明確な動作でした。たとえば、私にとっては、私が望んでいたqicoモジュールは、そのような構造にのみ静的に含まれます。

.proファイル内:

QTPLUGIN += qico
DEFINES += STATIC

main.cppで:

#ifdef STATIC
#include <QtPlugin>
Q_IMPORT_PLUGIN(qico)
#endif

おそらくそれは役立つでしょう。

于 2012-05-23T10:13:46.003 に答える