Qt for Linux/X11 - デプロイメント
このドキュメントでは、Qt for Linux/X11 のデプロイメントについて説明します。ここでは、Qt ソースパッケージに付属しているPlug & Paintサンプルアプリケーションのデプロイについて説明します。
Unix システム(商用 Unix、Linux ディストリビューションなど)が普及しているため、Unix でのデプロイは複雑なトピックです。始める前に、あるUnixフレーバー用にコンパイルされたプログラムは、おそらく異なるUnixシステムでは動作しないことに注意してください。例えば、クロスコンパイラを使わない限り、IrixでコンパイルしたアプリケーションをAIXで配布することはできません。
静的リンク
静的リンクは、Qt ライブラリを配布する作業から解放され、Qt ライブラリがターゲットシステムのデフォルトのライブラリ検索パスにあることを確認できるため、Unix 上でアプリケーションを配布する最も安全で簡単な方法です。
Qt を静的にビルドする
この方法を使うには、Qt ライブラリの静的バージョンのビルドから始めなければなりません。Qt for Linux/X11 - Building from Source のステップに従いますが、configure に-static
引数を追加することを忘れないでください:
mkdir -p ~/dev/qt-build cd ~/dev/qt-build /tmp/qt-everywhere-src-6.8.0/configure -static
アプリケーションを Qt の静的バージョンにリンクする
Qt を静的にビルドしたら、次は makefile を再生成してアプリケーションを再構築します。まず、アプリケーションのあるディレクトリに入ります:
cd /path/to/Qt/examples/widgets/tools/plugandpaint/app
qmakeを実行してアプリケーション用の新しいmakefileを作成し、静的にリンクされた実行ファイルを作成するためにクリーンビルドを行います:
make clean PATH=/path/to/Qt/bin:$PATH export PATH qmake -config release make
おそらくリリース・ライブラリーに対してリンクしたいでしょうから、qmake
を起動するときにこれを指定してください。おそらくリリース・ライブラリに対してリンクしたいでしょうから、 を呼び出すときにこれを指定することができます。
アプリケーションが本当に Qt と静的にリンクしているか確認するには、ldd
ツールを実行してください(ほとんどの Unices で利用可能です):
ldd ./application
出力にQtライブラリが含まれていないことを確認してください。
さて、すべてがエラーなくコンパイルされ、リンクされていれば、デプロイの準備ができたplugandpaint
ファイルができるはずです。アプリケーションが本当にスタンドアロンで実行できるかどうかを確認する簡単な方法の1つは、QtやQtアプリケーションがインストールされていないマシンにアプリケーションをコピーし、そのマシンで実行することです。
アプリケーションがコンパイラ固有のライブラリに依存している場合、これらのライブラリもアプリケーションと一緒に再配布する必要があることを覚えておいてください。詳しくは、アプリケーションの依存関係を参照してください。
Plug & Paint のサンプルはいくつかのコンポーネントで構成されています:コアアプリケーション(Plug & Paint)、Basic Toolsと Extra Filtersプラグインです。プラグインはスタティックリンクアプローチではデプロイできないため、これまで用意した実行ファイルは不完全なものです。アプリケーションは実行されますが、プラグインが欠けているため、機能は無効になります。プラグイン・ベースのアプリケーションをデプロイするには、共有ライブラリ・アプローチを使うべきです。
共有ライブラリ
共有ライブラリアプローチを使ってplugandpaint
アプリケーションをデプロイする場合、2つの課題があります:Qt ランタイムをアプリケーションの実行ファイルと一緒に正しく再配布すること、そしてプラグインをターゲットシステムの正しい場所にインストールし、アプリケーションがそれを見つけられるようにすることです。
共有ライブラリとしての Qt のビルド
Qt を共有ライブラリとして、/path/to/Qt
ディレクトリにインストール済みであると仮定します。
共有ライブラリとして Qt にアプリケーションをリンクする
Qt が共有ライブラリとしてビルドされていることを確認したら、plugandpaint
アプリケーションをビルドします。まず、アプリケーションを含むディレクトリに入ります:
cd /path/to/Qt/examples/tools/plugandpaint
qmakeを実行してアプリケーション用の新しいmakefileを作成し、クリーンビルドを行って動的にリンクされた実行ファイルを作成します:
make clean
qmake -config release
make
これでコア・アプリケーションがビルドされ、以下ではプラグインがビルドされる:
cd ../plugandpaint/plugins make clean qmake -config release make
すべてのコンパイルとリンクがエラーなしで完了すれば、plugandpaint
実行ファイルと、libpnp_basictools.so
とlibpnp_extrafilters.so
プラグイン・ファイルができあがります。
アプリケーション・パッケージの作成
Unixには標準的なパッケージ管理がないので、以下に紹介する方法は一般的なソリューションです。パッケージの作成方法については、ターゲットシステムのドキュメントを参照してください。
アプリケーションをデプロイするには、関連する Qt ライブラリ(アプリケーションで使用する Qt モジュールに対応)、プラットフォームプラグイン、実行ファイルを同じディレクトリツリーにコピーすることを確認する必要があります。アプリケーションがコンパイラ固有のライブラリに依存している場合、これらのライブラリもアプリケーションと一緒に再配布する必要があることを覚えておいてください。詳しくは、アプリケーションの依存関係のセクションを参照してください。
プラグインについては後ほど説明しますが、共有ライブラリの主な問題は、ダイナミックリンカーが Qt ライブラリを確実に見つけられるようにしなければならないということです。特に指示がない限り、ダイナミックリンカはアプリケーションが存在するディレクトリを検索しません。これを解決する方法はたくさんあります:
- Qt ライブラリをシステム・ライブラリ・パスの 1 つにインストールすることができます(たいていのシス テムでは
/usr/lib
など)。 - アプリケーションをリンクする際に、
-rpath
コマンドラインオプションに所定のパスを渡すことができます。これにより、アプリケーションを起動するときに、ダイナミック・リンカーにこのディレクトリを探すように指示します。 - アプリケーションのスタートアップ・スクリプトを作成し、ダイナミック・リンカ の設定を変更することができます(例えば、アプリケーションのディレクトリを
LD_LIBRARY_PATH
環境変数に追加します)。注意: アプリケーションを "実行時にユーザーIDを設定する "設定で実行し、 そのアプリケーションをrootが所有する場合、プラットフォームによっては LD_LIBRARY_PATHが無視されます。この場合、LD_LIBRARY_PATHを使用することはできません)。
最初の方法の欠点は、ユーザーがスーパー・ユーザー権限を持っていなければならないことである。2番目の方法の欠点は、ユーザーが所定のパスにインストールする権限を持っていない可能性があることである。いずれの場合も、ユーザーにはホームディレクトリにインストールするオプションがない。最も柔軟な方法であるため、3番目の方法を使用することを推奨する。たとえば、plugandpaint.sh
スクリプトは次のようになる:
#!/bin/sh appname=`basename $0 | sed s,\.sh$,,` dirname=`dirname $0` tmp="${dirname#?}" if [ "${dirname%$tmp}" != "/" ]; then dirname=$PWD/$dirname fi LD_LIBRARY_PATH=$dirname export LD_LIBRARY_PATH $dirname/$appname "$@"
実行ファイルの代わりにこのスクリプトを実行することで、ダイナミックリンカーが Qt ライブラリを確実に検出します。このスクリプトを他のアプリケーションで使用するには、スクリプトの名前を変更するだけでよいことに注意してください。
プラグインを探すとき、アプリケーションは実行ファイルのディレクトリ内の plugins サブディレクトリを検索します。plugins
ディレクトリに手動でプラグインをコピーするか、プラグインのプロジェクトファイルにDESTDIR
を設定します:
DESTDIR = /path/to/Qt/plugandpaint/plugins
すべての Qt ライブラリと、plugandpaint
アプリケーションの実行に必要なすべてのプラグインを配布するアーカイブには、以下のファイルを含める必要があります:
コンポーネント | ファイル名 | |
---|---|---|
実行ファイル | plugandpaint | |
実行スクリプト | plugandpaint.sh | |
Basic Toolsプラグイン | plugins\libpnp_basictools.so | |
ExtraFilters プラグイン | plugins\libpnp_extrafilters.so | |
Qt xcb platform プラグイン | platforms\libqxcb.so | |
Qt Core モジュール | libQt6Core.so.6 | |
Qt GUI モジュール | libQt6Gui.so.6 | |
Qt Widgets モジュール | libQt6Widgets.so.6 |
ほとんどのシステムでは、共有ライブラリの拡張子は.so
です。特筆すべき例外は HP-UX で、.sl
を使用しています。
アプリケーションがコンパイラ固有のライブラリに依存している場合、これらの ライブラリもアプリケーションと一緒に再配布する必要があります。詳細は、「アプリケーションの依存関係」セクションを参照してください。
アプリケーションが正常にデプロイできることを確認するには、Qt もコンパイラもインス トールされていないマシンでこのアーカイブを解凍し、plugandpaint.sh
スクリプト を実行してみてください。
plugins
サブディレクトリにプラグインを置く代わりに、QApplication::addLibraryPath() やQApplication::setLibraryPaths() を使ってアプリケーションを起動するときに、カスタム検索パスを追加することもできます。
QCoreApplication::addLibraryPath("/some/other/path");
アプリケーションの依存関係
追加ライブラリ
アプリケーションがどのライブラリに依存しているかを調べるには、ldd
(ほとんどのUnicesで利用可能)ツールを実行してください:
ldd ./application
このツールは、あなたのアプリケーションに依存するすべての共有ライブラリをリストアップします。設定によっては、これらのライブラリをアプリケーションと一緒に再配布する必要があります。特に、システム・コンパイラとバイナリの互換性がないコンパイラでアプリケー ションをコンパイルする場合は、標準 C++ ライブラリを再配布する必要があります。可能であれば、最も安全な解決策は、これらのライブラリに対して静的にリンクすることです。
実装によっては、他の共有ライブラリをdlopen()
で開こうとするものがあり、これに失敗するとX11ライブラリが原因でアプリケーションがクラッシュする可能性があるからです。
また、QtはXineramaやXrandrのような特定のX11拡張を探し、リンク先のすべてのライブラリを含め、それらを取り込む可能性があることも触れておく価値があります。特定の拡張機能が存在することを保証できない場合、最も安全な方法は、Qt を設定する際にその拡張機能を無効にすることです (例:./configure -no-xrandr
)。
FontConfig と FreeType は、常に利用できるとは限らない、あるいは常にバイナリの互換性があるとは限らないライブラリの他の例です。奇妙に聞こえるかもしれませんが、ソフトウェアベンダーの中には、非常に古いマシンでソフトウェアをコンパイルすることで成功を収め、そのマシンで動作するソフトウェアをアップグレードしないように細心の注意を払っているところもあります。
静的 Qt ライブラリに対してアプリケーションをリンクする場合、上記の依存ライブラリを明示的にリンクする必要があります。プロジェクトファイルのLIBS
変数に追加してください。
Qt プラグイン
すべての Qt GUI アプリケーションには、Qt のQPA(Qt Platform Abstraction)レイヤーを実装するプラグインが必要です。Linux/X11 の場合、プラットフォーム・プラグインの名前はlibqxcb.so
です。このファイルは、ディストリビューション ディレクトリの特定のサブディレクトリ(デフォルトではplatforms
)に配置する必要があります。また、以下に説明するように、Qt がプラグインを検索するパスを調整することもできます。
アプリケーションは、JPEG 画像フォーマットプラグインや SQL ドライバプラグインなど、1 つ以上の Qt プラグインに依存することもあります。必要な Qt プラグインは、必ずアプリケーションと一緒に配布してください。プラットフォーム・プラグインと同様に、各プラグインは配布ディレクトリ内の特定のサブディレクトリ(imageformats
やsqldrivers
など)に配置する必要があります。
Qt プラグインの検索パスは、QtCore ライブラリにハードコードされています。デフォルトでは、最初のプラグイン検索パスは/path/to/Qt/plugins
としてハードコードされます。上述したように、あらかじめ決められたパスを使用することにはデメリットがあるため、Qtプラグインが確実に見つかるようにするためには、さまざまな選択肢を検討する必要があります:
-
qt.conf
を使う。これは最も柔軟性があるため、推奨される方法です。 - QApplication::addLibraryPath() またはQApplication::setLibraryPaths() を使用する。
- サードパーティのインストールユーティリティまたはターゲットシステムのパッケージマネージャを使用して、QtCore ライブラリのハードコードされたパスを変更する。
Qt Plugins の作成方法」では、Qt アプリケーション用のプラグインをビルドし、デプロイする際に注意する必要のある事項の概要を説明しています。
©2024 The Qt Company Ltd. 本書に含まれるドキュメントの著作権は、それぞれの所有者に帰属します。 本書で提供されるドキュメントは、Free Software Foundation が発行したGNU Free Documentation License version 1.3に基づいてライセンスされています。 Qtおよびそれぞれのロゴは、フィンランドおよびその他の国におけるThe Qt Company Ltd.の 商標です。その他すべての商標は、それぞれの所有者に帰属します。