問題タブ [binary-compatibility]

私は ABI クロスチェック ツールを探し回っています。今、私はこれらの質問のような他の質問で提案されたツールのいくつかに会いました:

バイナリ互換性を自動的にテストする方法は?

C++ で ABI ブレークを検出する静的解析ツール

現在、これはまさに私がやろうとしていることではありません - これらはバージョン間の ABI の変更を追跡するためです。

特定のプロジェクト ソース ファイル + ライブラリ ヘッダー ファイルとライブラリ .so ファイル、およびコンパイラ バージョン (ライブラリとプロジェクトの両方のコンパイルに使用される) があれば、ABI の出力をクロス チェックできるのではないかと考えていました。コンパイルされたライブラリと一致しますか?

したがって、これが適用される状況は、アップストリーム ライブラリが libfoo.so および libfood.so を出荷した場合です。food の ABI は少し異なりますが (float ではなく double など)、コンパイルできないほどではありません。

• コンパイルされた実行可能ファイルが正しいライブラリにリンクされていることを示すテスト (おそらく防弾ではない) を考え出すことは可能ですか?
• これを行うツールはありますか？

2つのシナリオがあります。C ++シンボルをエクスポートする3つの共有ライブラリがあり、それぞれがVS7.1、VS8、およびVS9で構築されているとします。3つすべてをVS9でコンパイルします。何らかの理由で、これは機能します。シンボルを正常に見つけてそれらに対してリンクするために、VS9リンカー用にVS9の最初の2つのライブラリを再コンパイルする必要はありません。

さて、C構文（extern "C"）を使用してシンボルのみをエクスポートするライブラリがある場合、これは同じですか？ABI for Cは標準化されていると言われているので、VisualStudio8でコンパイルされたCライブラリをすべてのバージョンのVisualStudioで使用できるという保証があります。

基本的に、これらすべての組み合わせは混乱を招きます。異なるバージョンのVisualStudio間でC++ベースとCベースの両方の共有ライブラリ（対応するインポートライブラリを使用）に対してリンクすることについて、どのような保証があるのか​​わかりません。他のバージョンのVisualStudioでのCおよびC++インポートライブラリまたは静的ライブラリの両方の下位/下位互換性に関する一般的なコンセンサスを聞きたいです。

これが私に思い浮かんだ理由は、私が使用しているVisual Studio .NET 2003（VS7.1）でコンパイルされたクローズドソースライブラリがあるためです。私のチームは、これがVS 7.1コンパイラにロックされていると考えていますが、VS8とVS9の両方、さらにはVS2010でこれらのライブラリをテストし、正常にリンクしています。しかし、これに内在する危険性についてはよくわかりません。問題のライブラリにはCバリアントとC++バリアントがあることに注意してください。基本的に、Cバリアントは標準Cエクスポートであり、C++ライブラリはCライブラリとエクスポートクラスを抽象化したものです。

私はLobo - Java Web Browserライブラリを使用していますが、いくつかの調査の結果、ライブラリが古いバージョンの Java に対してコンパイルされていることが原因であると判断した例外が発生します。

コードは次のとおりです。

スタックトレースは次のとおりです。

調べてみると、以前のバージョンのJavaから変更されたorg.lobobrowser.util.gui.FontFactory.createFontというインターフェースがあることがわかりました。FontManagerこのFontFactoryクラスでは、使用できなくなったこのインターフェースのクラスを使用しました。この問題を解決するにはどうすればよいですか?

インターフェースFontManager:

および利用できないライブラリで使用されるクラス:

「実用的な API 設計」を読んでいて、次の段落を見つけました。

"フィールドよりもメソッドを優先するもう 1 つの理由は、JVM 仕様にあります。メソッドをクラスからそのスーパークラスの 1 つに移動しても、バイナリ互換性を維持することが許可されています。そのため、Dimension javax.swing として最初に導入されたメソッド.JComponent.getPreferredSize(Dimension d) は、JComponent が Component のサブクラスであるため、新しいバージョンでは削除され、Dimension java.awt.Component.getPreferredSize(Dimension d) に移動されます。このような変更は、JDK 1.2 で実際に行われました。これは、フィールドがメソッドによってカプセル化されたためにのみ実行できます. このような操作はフィールドには許可されていません. 一度フィールドがクラスで定義されると、バイナリ互換性を維持するために永遠にそこにとどまる必要があります. これは別の理由です.フィールドを非公開にする」

ゲッター/セッターを使用する方が良い方法であることに同意するからです。しかし、パブリック フィールドを親クラスに移動するとバイナリ互換性が失われる理由がわかりません。親でパブリックである限り、子クラスを介してそのフィールドにアクセスできるはずです。

SUSE Linux Enterprise Server (SLES) 用に構築された rpm があり、同じ rpm を Red Hat Enterprise Linux にインストールしたいとします。

• ここでアーキテクチャの依存関係の問題に直面することはありますか?
• ある OS 用に構築された rpm を別の OS にインストールする際の主な懸念事項は何ですか?
• インストールされたとしても、後で機能上の問題が発生する可能性はありますか?

メソッドまたはその他の「もの」からキーワードを削除した場合final、クラスのユーザーは再コンパイルする必要がありますか？

具体的には：

1. glibc 2.x のすべてのバージョンがバイナリ互換であることは、どういうわけか保証されていますか?

2. そうでない場合、別のバージョン用にコンパイルされたバイナリ (ゲーム) を自分のシステムで実行するにはどうすればよいですか? glibc を別のフォルダーにインストールできますか?

私の特定の問題は、glibc 2.14 (私が持っているもの) と 2.15 (ゲームが望んでいるもの) の間の互換性です。

glibc 2.13 用のバージョンも入手できるかもしれませんが、それが 2.14 で動作するかどうかはわかりません。

finalヘッダー ファイルで C++11 キーワードを条件付きで標準バージョンに有効にすることは良い考えですか? 私は次のようなことを考えています：

ここで 2 つの疑問があります。

1. ある方法とない方法finalがABI互換であるかどうか（私にはそう仮定するのが合理的であり、簡単なチェックでそれがg++確認されます）、
2. 誰かがメソッドをオーバーライドしようとしても、C++98 コンパイラは文句を言いません。しかし、メソッドをオーバーライドしないように文書化することで、これを処理できると思います。

Windowsでのパッケージ名に問題があるためaux、ライブラリのパッケージ階層内のヘルパー クラスを から移動しています。

に

クラスはライブラリに対してプライベートprivate[scalainterpreter] object Helperです。

Typesafe Migration-Managerを使用すると、明らかに、変更に互換性がないことが報告されます。

しかし、クライアント コードがどちらのオブジェクトも呼び出さない場合でも、インターフェイスには互換性があるのではないかと思います。そのため、マイナー バージョンの増加を使用して変更を示し、これら 2 つのバージョンを同じ意味で使用できるようにすることができます。

正しい？

C++ で永続的なデータ構造を書こうとしていますが、データ構造リーダーの他のさまざまな実装とバイナリ互換にすることができるはずだと感じているため、現在の考えは、抽象化せずにネイティブ メモリでデータ構造を宣言することです。 .

たとえば、メモリの線形ブロックを (newキーワードを使用して) データ構造として指定し、最初のバイトの意味、2 番目のバイトの意味などを記述します。を使用してこれを行うことができることはわかっていますstructが、データ構造は1つの言語にバインドされ、他の言語はこの構造を使用する必要があります。また、実装はコンパイラごとに変わる可能性があります。代わりに、メモリの標準として使用したいと思います。

私がやろうとしていることはやや賢明ですか？それとも、物事を単純化しすぎて、本当にstructデータ構造を進める必要がありますか? C++ の部分に移りましょう。データ構造を使用する必要があると思われる場合struct、本格的なクラスを使用することの欠点は何ですか?

（データ構造はとにかく永続的であるため、とにかくクラスを使用してメモリ構造をラップし、関数を提供しています。 ）クラスラッパーについては適切に述べられていません。つまり、メモリ表現用のクラス インターフェイスが必要であり、必ずしもラッパーである必要はありません。