问题标签 [binary-compatibility]

向后二进制兼容性（或向下兼容性） - 使用旧版本库 API 构建的客户端能够在新版本 ( wiki ) 上运行。

向上二进制兼容性（或向前兼容性）- 使用新版本的库 API 构建的客户端能够在旧版本 ( wiki ) 上运行。

Sun 关于自 1.4.2 以来 J2SE 5.0 中 JDK 不兼容性的一般文档（以及Java SE 6 与 J2SE 5.0的兼容性）描述了 JDK 的兼容性如下：

JDK 5.0与 Java 2 SDK v1.4.2向上二进制兼容，除了下面列出的不兼容性。这意味着，除了提到的不兼容性之外，使用 1.4.2 版编译器构建的类文件将在 JDK 5.0 中正确运行。

我想文档作者在这句话中混淆了术语“向上”和“向后”兼容性。他们描述了“向后”兼容性，但将此功能称为“向上”兼容性。

这是一个错字，错误或预期的术语吗？JDK“向上”还是“向后”兼容？

我目前正在编写一个库，并且正在考虑从 GCC 4.1.2 迁移到 GCC 的 4.5.2（最新版本）。如果我将我的代码编译成一个静态库，我可以假设编译器兼容性（显然在同一个操作系统上）对客户端来说应该不是问题吗？

编辑 进一步澄清：如果我向客户提供一个使用 gcc 4.5.2 编译的静态链接库，那么就他们必须使用的编译器和版本而言，这对该库的用户有什么限制？

假设我们有class X版本 1 的程序集A.dll：

然后在程序集的第 2 版中A.dll：

现在假设我们有第二个程序集B.dll加载A.dll并使用 X。添加属性会OtherProperty破坏 ABI 吗？将B.dll无法使用A.dll/ X？如果不是，声明的顺序会有什么不同吗？如果这些属性是虚拟的，它有什么不同吗？

我想我真的在问：一般的 ABI 规则是什么？我知道在发布后更改接口是一件坏事，但我真的希望能够在某些情况下添加属性，而无需添加子类。

初始说明：问题提到了 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。据我了解，我应该能够在 7.1 机器上运行基于 AIX 6.1 构建的 gcc，并生成可能不是最佳但完全有效的二进制文件，尽管它们需要 7.1 作为链接的副作用。

这看起来太像在闪闪发光的天空中跳舞的彩虹和独角兽。我闻到了腥味，但对 gcc 内脏一无所知。请各位大侠赐教。

tl;dr：gcc 是否可以在版本 N+1 上运行和使用基于版本 N 的 OS/平台构建并使用平台二进制兼容性来生成在版本 N+1 上运行的二进制文件？如果不是，什么机制可以阻止它？

我试图编译一个开源项目的二进制文件，这样我们的用户就不必自己编译它。

我注意到在一台 32 位 ubuntu 机器“A”上创建的一些二进制文件在 32 位机器“B”上不起作用，并且报告了有关丢失 .so 文件的错误。

但是，如果我在机器“B”上从头开始编译，那么所有错误都消失了。

为什么在目标机器上编译代码会使这些错误消失？我只运行了“./configure”和“make”——而不是“make-install”，所以它不像我让这些 .so 文件在全球范围内可用。

是不是编译器检测到系统库中缺少 .so 文件，在这种情况下将静态库链接到可执行文件？

Ubuntu 如何编译它的包以便 i386 包在所有 x86 机器上运行？

如果我有在 Solaris 8 和 10 下编译的代码，现在有一个供应商想在 Linux 下使用我的 bin/exe。会不会有兼容性问题？

我很确定我需要在 Linux 操作系统下编译/链接才能使其 100% 工作，但我只是想知道是否有人可以告诉我为什么它不能在 Linux 上工作，即使 exe 拥有一切并且在那里它没有什么动态的，因为它不需要任何进一步的东西来运行它。除非我们谈论运行时库，否则如果不匹配可能会导致 exe 失败。

我最初在win7 32bits上设计了一个win32应用程序，用VC9.0。我最近升级到win7 64位，并尝试构建+执行以前的应用程序。

构建运行良好（win32 应用程序），但在运行时我收到错误“[...] has exited with code -1073741701 (0xc000007b)”。

我猜这是加载[预期] 32 位 dll 的 64 位版本的结果。

这个项目的具体依赖是： SDL.lib SDLmain.lib SDL_ttf.lib opengl32.lib glu32.lib wininet.lib

SDL 和 SDL_ttf 仅在 32 位版本中。我假设 Visual Studio 足够聪明，可以在我请求 win32 应用程序时获取 \syswow64 中的 opengl 和 glu lib 文件。

难道是因为wininet？还是我犯了一个错误？

谢谢，

正如标题所说，如果我更改 vb.net 程序集的目标 cpu，它会破坏二进制兼容性吗？

我的意思不是“可移植”，您可以在 Linux 或其他任何东西下重新编译源代码，而是一个不需要安装的仅限 Windows 的应用程序，因此您只需放置 .exe 和一些 dll-s在一个文件夹中并将其复制到另一台机器上，它就可以工作了。

VS 2003 及更早版本根本不需要任何努力，但在 2008 中将丢失的 dll-s 放入同一文件夹不起作用，它需要安装可再发行组件。我记得听说过这个问题可以通过清单来解决，这是我以前从未遇到过的。

那么，我该怎么做呢？

我正在设计进行一些数学计算的 C 库。我需要指定序列化接口才能保存然后加载一些数据。问题是，在库的公共 API 中使用 FILE* 指针是否正确（从二进制兼容性的角度来看）？

目标平台有：

• Linux x86、x86_64 与 gcc >= 3.4.6
• Windows x86, x86_64 >= WinXP with VS >= 2008sp1

我需要尽可能多地兼容二进制文件，所以目前我的变体如下：

所以我很好奇使用 FILE* 或更好地切换到 wchar*/char* 是否正确？