C++ RHEL4 32bitで書かれたアプリケーションのRHEL6への移行64bit

Question

私はこれに関して一連の質問をしています。事実を簡単に、概念的に、実践的に試してみたいと思っています。

私のC++アプリケーションには、2007年のboost、antlr、libxml2などのサードパーティ製のライブラリがいくつかあります。-32ビットライブラリを-m32フラグ付きでコンパイルしています。アプローチ 上

質問私は、理想的には、64ビットRHEL6 OS上で32ビットからコピーすることで、アプリケーションを実行できるようにしたいだろうが、私はそれがセグメンテーションフォールトでクラッシュしていることを参照してください。私はまだ完成していないこれのための別の分析が必要です。

第2のアプローチは、すべての32ビットライブラリと32ビットコンパイラg ++ 3.4.6を使用して、-m32を使用して64ビットでアプリケーションをコンパイルすることでした。これは大丈夫です。しかし、私はマルチスレッドのlibsをブーストしてセグメンテーションフォルトを取得しています。理由についてもう少し調べる必要があります。

3番目のアプローチは、古いライブラリの一部のソースコードも64ビットアプリケーションとして64ビットで再コンパイルする必要があるため、非常に難しいものです。

私が取ることができる他のアプローチはありますか、私は私のアプローチで何かを逃しましたか？

Answer 1

私が取ることができる他のアプローチはありますか？ 私のアプローチには何かがありますか？

あなたは非常に明白なものを欠いています：ポートとアプリケーションをネイティブの64ビットアプリケーションとして構築します。

ネイティブの64ビットアーキテクチャに移行する際に問題が発生することがあります。しかし、理解しておくべき重要なことは、これらの問題が、元の32ビットプラットフォームで、これまで隠されていたか、検出されていない、あなたのコードの本当のバグであるということです。これは、それらを見つけて修正する絶好の機会になります。

ありましたか。

移行処理が完了すると、ネイティブの64ビットアプリケーションが終了します。これは、長期的なサポートが可能な限り最良の状態です。今週のニュースでは、普及しているLinuxディストリビューションabout discontinuing 32 bit support altogetherからのお知らせです。 32ビットが出ています。ある時点では、32ビットアプリケーションを実行するオプションがなくなります（ネイティブの32ビットLinuxディストリビューションがなければ、マルチバイト64/32リリースを構築する理由はありません）。 64ビットに整然とした移行サイクルを持つ時間がある間に、準備をして時間を投資してから、あなたの足元から敷物が引き抜かれたことを知り、次のLinuxプラットフォームは64ビットのみになります。ミッションクリティカルなアプリケーションは64ビットではありません。

マルチリブ互換ライブラリで問題となっていることは、マルチブロックビルド自体の問題とバグが原因であることに驚くことはありません。 multilibライブラリの需要は減少を続けています。時間が経つにつれ、彼らの使用はますます少なくなります。彼らはますます少なくなり、サポートも少なくなります。それ以上の時間を無駄にしてテストをして、まだ実際に動作していることを確認したいという人はいません。