問題タブ [binary-compatibility]

下位バイナリ互換性（または下位互換性）-古いバージョンのライブラリAPIで構築されたクライアントが、新しいバージョン（wiki）で実行できる機能。

上位バイナリ互換性（または上位互換性）-新しいバージョンのライブラリAPIで構築されたクライアントが、古いバージョン（wiki）で実行できる機能。

1.4.2以降のJ2SE5.0でのJDKの非互換性に関する一般的なSunのドキュメント（およびJava SE6とJ2SE5.0との互換性）では、JDKの互換性について次のように説明しています。

JDK 5.0は、以下にリストされている非互換性を除いて、Java 2 SDK、v1.4.2と上位バイナリ互換です。これは、上記の非互換性を除いて、バージョン1.4.2コンパイラでビルドされたクラスファイルがJDK5.0で正しく実行されることを意味します。

この文では、ドキュメント作成者が「上位」と「下位」の互換性という用語を混同していると思います。これらは「下位」互換性について説明していますが、この機能を「上位」互換性と呼んでいます。

これはタイプミス、間違い、または意図された用語ですか？JDKは「上向き」または「後方」互換性がありますか？

私は現在ライブラリを作成しており、GCC 4.1.2から4.5.2（最新リリース）のGCCへの移行を検討しています。コードを静的ライブラリにコンパイルする場合、コンパイラの互換性（明らかに同じOS上で）はクライアントにとって問題ではないと想定できますか？

編集 さらに明確にするために：gcc 4.5.2でコンパイルされた静的にリンクされたライブラリをクライアントに提供する場合、使用する必要のあるコンパイラとバージョンに関して、このライブラリのユーザーにどのような制限がありますか？

アセンブリclass Xのバージョン 1 があるとしますA.dll。

次に、アセンブリのバージョン 2 でA.dll:

ここで、XB.dllを読み込んで使用する 2 つ目のアセンブリがあるとします。プロパティを追加すると ABI が壊れますか? /の使用に失敗しますか? そうでない場合、宣言の順序に違いはありますか? プロパティが仮想であった場合、違いはありましたか?A.dllOtherPropertyB.dllA.dllX

私は本当に質問していると思います: 一般的な ABI ルールとは何ですか? 公開後にインターフェイスを変更するのは良くないことだとわかっていますが、サブクラスを追加せずに、一部のインスタンスでプロパティを追加できるようにしたいと考えています。

最初のメモ: AIX は最初のコンテキストであるため、質問は AIX に言及していますが、質問は実際にはプラットフォームに関係なく gcc 自体に関係しています。

AIX は下位バイナリ互換であると想定されています。AIX 5.1 でコンパイルされた C プログラムは、5.2、5.3、6.1、および 7.1 でそのまま実行されます。

私の理解では、gcc は特定のシステム (クロスコンパイルの場合は現在のシステムか別のシステムか) をターゲットにするようにビルドする必要があります。そのため、AIX 6.1 上に構築された gcc は AIX 6.1 をターゲットとし、バイナリ互換性のおかげで 6.1 と 7.1 の両方で使用可能なバイナリを生成します。

ただし、AIX 6.1 上にビルドされた gcc 自体は 6.1 プログラムなので、7.1 上でそのまま実行する必要があります。もちろん、7.1 でプログラムをコンパイルすると、このプログラムはリンクされたり、7.1 に固有のヘッダーを使用したりする可能性があるため、7.1 を必要とするバイナリが生成されます。私が理解している限りでは、AIX 6.1 でビルドされた gcc を 7.1 マシンで実行でき、リンクの副作用として 7.1 が必要になるものの、最適ではないものの完全に有効なバイナリを生成できるはずです。

これは、きらめく空で踊る虹やユニコーンのように見えます. 何か怪しい匂いがしますが、gcc 内部の知識がありません。大群衆よ、私を啓発してください。

tl;dr : OS/プラットフォームのバージョン N を対象として構築された gcc は、バージョン N+1 で実行されるバイナリを生成するプラットフォーム バイナリ互換性により、バージョン N+1 で実行および使用できますか? そうでない場合、それを防ぐメカニズムは何ですか？

ユーザーが自分でコンパイルする必要がないように、オープンソース プロジェクトのバイナリをコンパイルしようとしています。

1 つの 32 ビット ubuntu マシン「A」で作成された一部のバイナリが、32 ビット マシン「B」では機能せず、欠落している .so ファイルに関するエラーが報告されていることに気付きました。

ただし、マシン「B」で最初からコンパイルすると、すべてのエラーがなくなります。

ターゲット マシンでコードをコンパイルすると、これらのエラーがなくなる理由はありますか? 「./configure」と「make」のみを実行し、「make-install」は実行しなかったため、これらの .so ファイルをグローバルに利用できるようにしたわけではありません。

コンパイラが、システム ライブラリにない .so ファイルがあることを検出し、この場合、スタティック ライブラリを実行可能ファイルにリンクしている可能性がありますか?

i386 パッケージがすべての x86 マシンで実行されるように、Ubuntu はどのようにパッケージをコンパイルしますか?

Solaris 8および10でコンパイルされたコードがあり、Linuxでbin/exeを使用したいベンダーがいる場合。互換性の問題はありますか？

Linux OSで100％動作させるには、コンパイル/リンクする必要があると確信していますが、exeにすべてが含まれているにもかかわらず、Linuxで動作しない理由について誰かが私に内訳を教えてくれるかどうかを知りたいだけです。それを実行するためにそれ以上何も必要としないはずなので、それについて動的なものは何もありません。ランタイムライブラリについて話していない限り、不一致があるとexeが失敗する可能性があります。

私はもともと、VC9.0を使用してwin732ビットでwin32アプリケーションを設計しました。最近、win7 64ビットにアップグレードし、前のアプリケーションをビルドして実行しようとしました。

ビルドは正常に実行されますが（win32アプリケーション）、実行時に「[...]はコード-1073741701（0xc000007b）で終了しました」というエラーが表示されます。

これは、[意図された]32ビットdllの64ビットバージョンをロードした結果だと思います。

このプロジェクトの具体的な依存関係は次のとおりです。SDL.libSDLmain.libSDL_ttf.libopengl32.lib glu32.lib wininet.lib

SDLとSDL_ttfは32ビットバージョンのみです。Win32アプリケーションを要求すると、VisualStudioは\syswow64内のopenglファイルとglulibファイルをフェッチするのに十分賢いと思います。

それはwininetのせいでしょうか？それとも私は間違いを犯しましたか？

ありがとう、

タイトルにあるように、vb.netアセンブリのターゲットCPUを変更すると、バイナリ互換性が失われますか？

Linux などでソース コードを再コンパイルできるような「ポータブル」という意味ではなく、インストールを必要としない Windows 専用のアプリケーションであるため、.exe といくつかの dll-s をフォルダーに入れ、それを別のマシンにコピーすると機能します。

VS 2003 以前ではまったく労力を必要としませんでしたが、2008 では不足している dll-s を同じフォルダーに配置しても機能せず、再配布可能ファイルをインストールする必要があります。マニフェストで問題が解決できると聞いたのを覚えていますが、これまでに遭遇したことはありません。

それで、どうすればそれを行うことができますか？

いくつかの数学的計算を行う C ライブラリを設計しています。データを保存してからロードできるようにするには、シリアライゼーション インターフェイスを指定する必要があります。問題は、(バイナリ互換性の観点から) ライブラリのパブリック API で FILE* ポインターを使用することは正しいですか?

ターゲット プラットフォームは次のとおりです。

• Linux x86、gcc >= 3.4.6 を使用する x86_64
• Windows x86、x86_64 >= VS 搭載の WinXP >= 2008sp1

可能な限りバイナリ互換性を持たせる必要があるため、現時点で私のバリアントは次のとおりです。

だから、 FILE* を使用するのが正しいのか、それとも wchar*/char* に切り替えるのが正しいのか知りたいです。