問題タブ [binary-compatibility]

異なるリリース間でScalaバイナリに互換性がないのはなぜですか？

一般に、C および C++ 標準は、コンパイラの作成者に多くの自由を与えていることを認識しています。しかし特に、C 構造体メンバーのような POD 型は、構造体定義にリストされているのと同じ順序でメモリに配置する必要があることが保証されます。また、ほとんどのコンパイラは、メンバーの配置を修正できる拡張機能を提供します。したがって、構造体を定義し、そのメンバーの配置を手動で指定するヘッダーがあり、そのヘッダーを使用して異なるコンパイラで 2 つのアプリをコンパイルした場合、一方のアプリが構造体のインスタンスを共有メモリに書き込み、他方のアプリが共有メモリに書き込むことができないはずです。アプリはエラーなしでそれを読むことができますか?

ただし、含まれる型のサイズは、同じアーキテクチャ上の 2 つのコンパイラ間で一貫していると想定しています (共有メモリについて話しているので、既に同じプラットフォームである必要があります)。一部の型 (GCC および MSVC 64 ビットでの long と long long など) ではこれが常に当てはまるとは限りませんが、最近では uint16_t、uint32_t などの型があり、float と double は IEEE 標準で指定されています。

このツールhttp://sab39.netreach.com/Software/Japitools/JDK-Results/46/を見つけました。このツールは、javadoc を使用して異なるバージョンの Java 用 API 間の後方互換性をチェックします。

C#/.NET 用のこれと同等のツールはありますか?

このツールを使用した JDK 1.5 API と JDK 6 API の比較の例を次に示します: http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-jdk6

私のプロジェクトでは、g++とnvcc（cudaコンパイラ）の2つの異なるC++コンパイラを使用しています。nvccオブジェクトファイルからスローされた例外がg++オブジェクトファイルでキャッチされないことに気づきました。

C ++例外は、同じマシンでバイナリ互換であると想定されていますか？何がそのような行動を引き起こす可能性がありますか？

他のすべては機能しているようです（C ++オブジェクト、演算子）。正直なところ、私は例外をよく知らないので、上記のコードに間違いがあるかもしれません。

私のプロジェクトは元々バイナリ互換性に設定されていましたが、構築されていませんでした。だから私は最初にそれを互換性なしに設定しました、それはそのようにうまく構築されました。次に、それをバイナリ互換性に戻し、以前に生成されたファイルを上書きすると、正常に機能しました。

なぜこれが起こらなければならないのですか？

Linux Standard Base http://www.linuxfoundation.org/collaborate/workgroups/lsbから LSB C++ Compiler を使用してプログラムをビルドしたいと考えています。プログラムは、gcc 4.4 バージョンでビルドされた Boost ライブラリに依存します。コンパイルが失敗します。LSB C++ Compiler で Boost ライブラリをビルドすることはできますか? あるいは、Boost ライブラリを古い gcc バージョンでビルドすることは可能ですか?どのバージョンが推奨されますか? 私の最終的な目標は、ほとんどの Linux ディストリビューションで、私の実行可能ファイルとサードパーティの Boost ライブラリを実行することです。

一般的に、Linux ディストリビューションのバイナリ互換性を向上させ、Boost ライブラリに依存する C++ クローズド ソース アプリケーションを開発するにはどうすればよいでしょうか?

Javaでは、具象メソッドと抽象メソッドの両方を含む抽象クラスを定義しており、サードパーティの開発者が独自にサブクラス化する必要があります。念のために言っておきますが、抽象クラスにソース互換性はあるがバイナリ互換性はない変更を加えることはできますか？言い換えれば、サブクラスをコンパイルした後、抽象クラスを変更できますか？たとえば、抽象メソッドを追加したり、サブクラスによって呼び出される保護されたメソッドを削除したりすることはできませんが、もちろんソースとは互換性がありませんそれは彼らに彼らのサブクラスを再コンパイルすることを強制することができますか？

クラス宣言の最後に仮想関数を追加すると、バイナリの非互換性が回避される理由を誰かに説明してもらえますか?

私が持っている場合：

その後、このクラス宣言を次のように変更します。

前の宣言に対してコンパイルされた別の .so からコアダンプを取得します。しかし、クラス宣言の最後 (「int someVal」の後) に someFuncC() を配置すると、次のようになります。

コアダンプが表示されなくなりました。誰かがこれがなぜなのか教えてもらえますか? そして、このトリックは常に機能しますか?

PS。コンパイラは gcc ですが、これは他のコンパイラで動作しますか?

日中の仕事では、私たちが作成した多数のライブラリを使用する VB6 アプリケーションに取り組んでいます (これも輝かしい VB6 です)。これらのサポート ライブラリの 1 つに、パブリック プロパティを介して公開された多数のプライベート メンバーがあり、そのプロパティを削除し、プライベート メンバー変数を元のプロパティと同じ名前のパブリック フィールドに昇格するように求められました。

さて、私は COM の専門家ではありませんが、クラスで公開されているすべての項目が独自の GUID を取得するという印象を受けました。各値が 2 つの Guid (Property Get と Property Let) から 1 つ (public フィールド) のみを使用する状況に移行するため、バイナリ互換性が損なわれると予想していましたが、そうではないようですやってない。

誰でも理由を説明できますか？

Android ndk は古い autoconf ベースのコードでは使いにくいため、scratchbox2/emdebian を使用して完全なビルド環境を用意しました。emdebian (arch は armel) で共有ライブラリを構築し、それを Android で使用できますか?