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のバージョンの不一致は、
binutils
Binutilsがlibtool
glibcに依存し、libtoolがbinutilsに依存するため、libtool
間接的に依存する場合に発生します。glibc
なぜすべてのシステムのほとんどすべてのパッケージが間接的に依存するのか説明しませんglibc
。はい。 - 正しくインストールされたビルドツールチェーンがC ++ 11をサポートしていない場合、OPは現在直面している問題を軽減するためにC ++ 98を使用する必要があります。
- 上記の手順1でビルドツールバーを更新した後、OPはCentOS VMでソースコードをコンパイルし、必要に応じて修正/修正を実行する必要があります。 OPにパッケージが必要な場合は、この記事が示すようにrpmbuildを使用する必要があります。これは、パッケージが存在するVMのデフォルトのパッケージマネージャであるためです。 Yumはパッケージマネージャではありません。 Yumは依存関係パーサーです。
引用する
答え2
OPソリューションと結論
以前の答えに基づいて、これが私が解決したソリューションです。
1. ソースコードのコピー
ソースコードを仮想マシンまたは別のコンピュータにコピーします。私は以下を使用しました:
scp -R /host/path/to/src/ user@remoteHost:/remote/build/path/
これは自動車旅行と同じですので、他のコンピュータで見つけることができる共有ライブラリやその他のリソースを除いて、コンパイルに必要なすべてのソースコードをパッケージ化して収集します。
2. 依存関係のインストール(ライブラリ/ビルドツール)
VMをデフォルトのインストール(centOS7分)に復元し、試行錯誤に基づいてアプリを構築するための更新されたツール(yum search、install、try buildコマンド)
yum -y update
yum -y install boost-* #probably could have used only boost-devel
yum -y install glibc-utils
yum -y install gcc-c++
yum -y install git
yum -y install libtool
yum -y install zlib-devel
yum -y install ncurses-devel
yum -y install make
yum -y install cmake
yum -y install openssl-devel
yum -y install libssh2-devel
...
プロジェクトがオペレーティングシステムリポジトリで利用できない(最新の)ライブラリに依存している場合は、ソースからインストールしてください。
たとえば、c-aresと更新されたmysqlクライアントライブラリで構築されたカールを使用する必要があります。
#mysqlclient
if [[ -z $(ldconfig -p | grep libmysqlclient) ]]
then
mkdir -p "${INSTALL_PREQ_PATH}/lib/mysql/";
cd "${INSTALL_PREQ_PATH}lib/mysql/"
wget http://dev.mysql.com/get/mysql-community-release-el7-5.noarch.rpm
yum -y localinstall mysql-community-release-el7-5.noarch.rpm
sudo yum install mysql-community-client
sudo yum install mysql-community-devel
fi
#c-ares
if [[ -z $(ldconfig -p | grep libcares) ]]
then
mkdir -p "${INSTALL_PREQ_PATH}lib/libcares/"
cd "${INSTALL_PREQ_PATH}lib/libcares/"
git clone git://github.com/bagder/c-ares.git
cd c-ares
./buildconf
./configure
make
sudo make install
ldconfig
fi
#libcurl
if [[ -z $(ldconfig -p | grep libcares) ]]
then
mkdir -p "${INSTALL_PREQ_PATH}lib/libcurl/"
cd "${INSTALL_PREQ_PATH}lib/libcurl/"
wget http://curl.haxx.se/download/curl-7.39.0.tar.gz
tar -xvzf curl-7.39.0.tar.gz
cd curl-7.39.0
./configure --enable-ares --with-libidn --with-zlib --disable-ipv6
make
sudo make install
ldconfig
fi
観察する: 各ビルドには、上記の手順に追加された独自の依存関係があります。
3. Foreach 依存関係をインストールし、動作していることを確認し、問題があるかどうかを確認しました。
システムにライブラリがロードされていることを確認してください。
ldconfig # update library cache
ldconfig -p | grep libcurl # check for library
私の場合、デフォルトではLink Builder検索パスに含まれていない/ usr / local / lib /フォルダにライブラリがインストールされていました。この問題を解決するには:
echo "/usr/local/lib/">/etc/ld.so.conf.d/local.conf #add lib search path
ldconfig #reload library cache
また、共有ライブラリを使用する他のプログラムがまだ機能していることを確認してください。私の場合、sshとsslが欠落しており、カールのインストールが中断されました。以下を修正してください。
rm /etc/ld.so.conf.d/local.conf #remove the new libs search path
ldconfig #reload
yum install openssl-devel #install ssl dependency
yum install libssh2-devel #install ssh dependency
cd "${INSTALL_PREQ_PATH}lib/libcurl/" #go to libcurl source path
./configure --enable-ares --with-libidn --with-zlib --disable-ipv6 --with-ssl --with-libssh2 # configure build with ssl and ssh
make #compile
sudo make install #install binary, libs and headers
echo "/usr/local/lib/">/etc/ld.so.conf.d/local.conf #add lib search path
ldconfig #reload library cache
4. プログラム構築
私の場合は、Ubuntuのようなコンパイラであるgcc-c ++(g ++)を使用しました。うまくいかない場合:
- 依存関係がないことを確認し、警告とエラーを読んでください。
- 両方のシステムのコンパイラバージョンを確認し、コードとコンパイラフラグのサポートの違いを確認し、インターネットを使用してオペレーティングシステムに合わせてコンパイラを更新する方法を見つけます。
その他の注意事項:
- 他のコンピュータに再試行または再インストールできるように、手順をbashスクリプトに記録することをお勧めします。
- これは生産機械のための良い提案ではありません。他の場所で試してみてください。
- 仮想マシンを使用している場合はスナップショットを撮り、そうでない場合はバックアップを作成し、常に失敗に備えてください。
- 私のアドバイスを受け入れないでください。これは私にとって効果的でした。誰にも効果がないかもしれませんし、他の状況では悪い選択かもしれません。私は専門家ではなく、私のような初心者に助けを求めて書いています:)