CentOS 7（両方とも64ビット、1つのホスト、1つの仮想マシン）で実行するためにUbuntuでバイナリをコンパイルしようとしています。
これまで、すべての共有ライブラリを含むバイナリをコピーしました。ライブラリの欠落エラーは発生しなくなりますが、素晴らしいld SIGSEGVが表示されます。
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff5d67681 in ?? ()
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.149.el6.x86_64
(gdb) where
#0 0x00007ffff5d67681 in ?? ()
#1 0x00007fffffffe3f0 in ?? ()
#2 0x00007ffff7decdd4 in _dl_check_map_versions () from /lib64/ld-linux-x86-64.so.2
#3 0x00007ffff7de08a3 in dl_main () from /lib64/ld-linux-x86-64.so.2
#4 0x00007ffff7df2aee in _dl_sysdep_start () from /lib64/ld-linux-x86-64.so.2
#5 0x00007ffff7dde4a4 in _dl_start () from /lib64/ld-linux-x86-64.so.2
#6 0x00007ffff7dddb08 in _start () from /lib64/ld-linux-x86-64.so.2
#7 0x0000000000000001 in ?? ()
#8 0x00007fffffffe8bb in ?? ()
#9 0x0000000000000000 in ?? ()
私はソースコードを持っていますが、ソースからビルドされたいくつかのライブラリに依存し、centOSで試してみましたが、g ++バージョンが古く、c ++ 11をサポートしていないため、Ubuntuではほとんどコンパイルしてテストできません。 devtoolsバージョンをインストールした後、別のエラーが発生しますが、これは他の問題のようです。
それでは、このエラーを克服するために私ができることはありませんか？結局こんなことでしょうか？ UbuntuからCentOSに移植する最も簡単な方法は何ですか？
ベストアンサー1
私はこれをしないことをお勧めします。通常、ディストリビューションのパッケージ作成プロセス中に、さまざまなディストリビューションのバイナリを作成する方が簡単です。 CentOSではrpmbuild。
VMを扱っているので、CentOS 7 VM +ビルドツールを設定し、そこでパッケージビルドを実行する方が簡単です。
ソースベースのディストリビューションユーザーの観察
私は一般的に他の人の答えを編集する傾向に従わないが、人々がソースベースのディストリビューションの違いを認識するのを助けることによって遅いが、確かにここで評判を得ている。そのうちの3つの主要なディストリビューションは次のとおりです。
さらに、バイナリベースのディストリビューションには2つの主要なディストリビューションがあります。
現時点では、主要なハイブリッドディストリビューションは1つだけです（ソースコードとバイナリ間の交差）。
Linuxユーザーが好きでも嫌いでも、他のすべてのLinuxディストリビューションは、これら6つの親バージョンのうちの1つのサブバージョンです。そう言って次のポイントに進みましょう。
ソースベースのディストリビューションのソフトウェアとバイナリディストリビューションのソフトウェアを混在させることは不可能です。
これを知っていることも、実行していることがわからない限り、バイナリディストリビューションのソースから個々のパッケージをコンパイルしないでください。。このルールには例外があります。
- 必要なパッケージが配布リポジトリ/ツリー/などに存在しません（これがOPが質問した理由です）。
- あなたは一つを見つけることができませんリポジトリ/ツリー/などの必須パッケージの最新バージョン - 項目9を参照。
OPになぜ問題がありますか？
技術的に言えば、最終パッケージの場合、パッケージの使用とソースからのビルドの間に違いはありません。つまり、パッケージを正常にビルドして動作すれば、誰もそうすることを非難することはできません。ただし、これを行う場合、あるバイナリベースのディストリビューションでアプリケーションを構築するために使用されるツールは、他のバイナリディストリビューションで使用できるツールよりも高いバージョンであることに注意してください。 OPが見ているのは、古いパッケージと新しいパッケージの間のデルタまたは変更です。上記の6つのオペレーティングシステムのいずれか、サブオペレーティングシステムであるかどうかにかかわらず、各オペレーティングシステムのパッケージとオペレーティングシステム管理者がそのオペレーティングシステムに対して信頼できるとマークされるパッケージを選択することで、増加または変更が発生します。バイナリリリース用にパッケージを選択すると、ほとんどの場合、次のリリースまで固定されます。重大なエラー発見されました。
一方、ソースベースのディストリビューションには、新しいソースが提供されるとすぐにプロジェクトを更新してすぐにバグを修正するオプションがあります。
これがOPに問題がある理由です。
Ubuntuのリリーススケジュールとアップデートサイクルは、新しいバージョンを採用することを選択します。ツールチェーンビルド、CentOSがこれを採用する前に。 CentOSは信頼性に基づいて構築されているため、次のリリースまでビルドツールチェーンが更新されない可能性があります。メジャーバージョン。そのため、OPに問題が発生しました。これに似て、UbuntuのビルドツールチェーンはC ++ 11をサポートしますが、CentOSのビルドツールチェーンはすべてのバージョンの不一致が修正されるまでそれをサポートしておらず、後で複数のパッケージマネージャを使用すると問題が発生するためです。
OPは何をすべきですか？
- パッケージがホストされているシステムで使用できるビルドツールを決定します。この場合はCentOSです。ここに一つあります。正しくインストールする方法のページ。前のリンクのリストによると、このコンパイラはC ++ 11をサポートしています。非常に熟練した直感として、OPのバージョンの不一致は、
binutilsBinutilsがlibtoolglibcに依存し、libtoolがbinutilsに依存するため、libtool間接的に依存する場合に発生します。glibcなぜすべてのシステムのほとんどすべてのパッケージが間接的に依存するのか説明しませんglibc。はい。 - 正しくインストールされたビルドツールチェーンがC ++ 11をサポートしていない場合、OPは現在直面している問題を軽減するためにC ++ 98を使用する必要があります。
- 上記の手順1でビルドツールバーを更新した後、OPはCentOS VMでソースコードをコンパイルし、必要に応じて修正/修正を実行する必要があります。 OPにパッケージが必要な場合は、この記事が示すようにrpmbuildを使用する必要があります。これは、パッケージが存在するVMのデフォルトのパッケージマネージャであるためです。 Yumはパッケージマネージャではありません。 Yumは依存関係パーサーです。