3

最近、多くのLinuxディストリビューションでデプロイされる自己完結型の実行可能ファイルを作成するために何を使用すべきかについて質問しました。最初はとても怖かったのですが、C ++について少し読んだ後、実行可能ファイルの最初のバージョンを実行することができました。

喜びに満ちた一日を過ごした後、私は別のジレンマで再び壁にぶつかりました。結果として得られる実行可能ファイルは、多くのLinuxディストリビューション(Slackware、Arch、Ubuntu、Debian、CentOSなど)にインストールする必要がありますが、その方法についてはまったくわかりません。CentOSとDebianベースのOSにはaptやyumなどのパッケージマネージャーがあることを私は知っていますが、それらが私の場合に当てはまるかどうかはわかりません。

私が書いたコードは、いくつかのライブラリ(より具体的にはRudeSocketyaml-cpp )に依存します。実行可能ファイルをコンパイルして動的にリンクできると言われているので、実行可能ファイルを配布する必要がありました。

yaml-cppライブラリの.aファイルが見つからなかったことがあります(RudeSocketの場合のみ)。そして、これまでの私の問題は次のとおりです。

最初はダイナミックリンクを使用しましたが、(明らかに)実行可能ファイルを別のボックスにコピーすると、次のようになります。

$ ./main
./main: error while loading shared libraries: libyaml-cpp.so.0.2: cannot open shared object file: No such file or directory

静的にコンパイルしようとすると、エラーも発生します(前述のようにyaml-cpp .aファイルがないため):

$ g++ main.cpp parse.cpp parse.h rudesocket-1.3.0/.libs/librudesocket.a -o main -static -L/usr/local/librudesocket-1.3.0/.libs/librudesocket.a(socket_connect_normal.o): In function `rude::sckt::Socket_Connect_Normal::simpleConnect(int&, char const*, int)':
/root/webbyget/sockets/rudesocket-1.3.0/src/socket_connect_normal.cpp:250: warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/tmp/cc3cEVK1.o: In function `operator>>(YAML::Node const&, Job&)':
parse.cpp:(.text+0x1a83): undefined reference to `YAML::Node::size() const'
/tmp/cc3cEVK1.o: In function `handle_job(rude::Socket, char const*)':
parse.cpp:(.text+0x1b79): undefined reference to `YAML::Parser::Parser(std::basic_istream<char, std::char_traits<char> >&)'
parse.cpp:(.text+0x1bfd): undefined reference to `YAML::Node::Node()'
parse.cpp:(.text+0x1c10): undefined reference to `YAML::Parser::GetNextDocument(YAML::Node&)'
parse.cpp:(.text+0x1dc6): undefined reference to `YAML::Node::size() const'
parse.cpp:(.text+0x1dee): undefined reference to `YAML::Node::~Node()'
parse.cpp:(.text+0x1e18): undefined reference to `YAML::Node::~Node()'
parse.cpp:(.text+0x1e37): undefined reference to `YAML::Parser::~Parser()'
parse.cpp:(.text+0x1e61): undefined reference to `YAML::Parser::~Parser()'
(...)

g ++は、yaml-cppのクラスの場所を指定せずに、静的にコンパイルできないことは私には非常に明白です。

インストールは、人間の介入なしに、自動化された方法で行われることが非常に重要です。

だから私の質問は本当に2つあります:

  • これらすべてのディストリビューションを対象に、このコンパイル済みプログラムを最も複雑でない方法で配布するにはどうすればよいですか?

  • この種の問題に対する事実上の標準的な解決策はありますか?

前もって感謝します、

フェリペ。

4

4 に答える 4

4

このテクニックを試してみてください。

于 2009-09-16T17:17:42.853 に答える
0

プラットフォームパッケージマネージャー(.rpmまたは.deb)を使用する場合、システムは共有ライブラリの正しいバージョンを確認し、必要に応じてダウンロードします。

CPackはおそらく最も簡単なパッケージジェネレータです

于 2009-09-16T17:30:28.673 に答える
0

多くのデファクトスタンダードがありますが、どれも標準化されていません。:(コンパイルされたバイナリを配布したい場合は、ターゲットにするプラットフォームごとにパッケージを作成することをお勧めします。rpmとdebを生成すると、おそらく90%の方法で取得できます。ビルドを自動化する場合プロセス、autoconf / automakeはまだ(おそらく)最善の方法です。

于 2009-09-13T22:09:25.960 に答える
0

たぶんあなたにとって最良の解決策はCMakeを使うことです。

CMakeは、クロスプラットフォームのオープンソースビルドシステムです。これは、ソフトウェアを構築、テスト、およびパッケージ化するために設計されたツールのファミリーです。パッケージングについては、Mgbが適切であり、CMakeはCPackと簡単に組み合わせることができます

KDEはこのソリューションを使用しており、automake/autoconfの非常に優れた代替手段です。

于 2009-09-23T10:09:09.860 に答える