Linux 可执行文件是否与 OS X“兼容”?

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/9439436/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-08-06 04:48:36  来源:igfitidea点击:

Is a Linux executable "compatible" with OS X?

clinuxmacoscompilationexecutable

提问by bgroenks

If you compile a program in say, C, on a Linux based platform, then port it to use the MacOS libraries, will it work?

如果你在基于 Linux 的平台上用 C 编译一个程序,然后将它移植到使用 MacOS 库,它会工作吗?

Is the core machine-code that comes from a compiler compatible on both Mac and Linux?

来自编译器的核心机器代码在 Mac 和 Linux 上都兼容吗?

The reason I ask this is because both are "UNIX based" so I would think this is true, but I'm not really sure.

我问这个的原因是因为两者都是“基于 UNIX”的,所以我认为这是真的,但我不确定。

采纳答案by Tom

No, Linux and Mac OS X binaries are not cross-compatible.

不,Linux 和 Mac OS X 二进制文件不能交叉兼容。

For one thing, Linux executables use a format called ELF.

一方面,Linux 可执行文件使用一种称为ELF的格式。

Mac OS X executables use Mach-O format.

Mac OS X 可执行文件使用Mach-O 格式

Thus, even if a lot of the libraries ordinarily compile separately on each system, they would not be portable in binary format.

因此,即使许多库通常在每个系统上单独编译,它们也不会以二进制格式进行移植。

Furthermore, Linux is not actually UNIX-based. It does share a number of common features and tools with UNIX, but a lot of that has to do with computing standards like POSIX.

此外,Linux 实际上并不是基于 UNIX 的。它确实与 UNIX 共享许多共同的特性和工具,但其中很多都与 POSIX 等计算标准有关。

EDIT:

编辑:

Finally, to address your point on byte-code: when making a binary, compilers usually generate machine codethat is specific to the platform you're developing on. (This isn't always the case, but it usually is.)

最后,为了解决您对字节码的看法:在制作二进制文件时,编译器通常会生成特定于您正在开发的平台的机器代码。(情况并非总是如此,但通常如此。)

回答by Kerrek SB

There is no "core byte-code that comes from a compiler". There is only machine code.

没有“来自编译器的核心字节码”。只有机器码

While the same machine instructions may be applicable under several operating systems (as long as they're run on the same hardware), there is much more to a hosted executable than that, and since a compiled and linked native executable for Linux has very different runtime and library requirements from one on BSD or Darwin, you won't be able to run one binary on the other system.

虽然相同的机器指令可能适用于多个操作系统(只要它们在相同的硬件上运行),托管可执行文件的内容远不止这些,而且由于 Linux 的编译和链接的本机可执行文件有很大不同BSD 或 Darwin 上的运行时和库要求,您将无法在另一个系统上运行一个二进制文件。

By contrast, Windows binaries cansometimes be executed under Linux, because Linux provides both a binary format loader for Windows's PE format, as well as an extensive API implementation (Wine). In principle this idea can be used on other platforms as well, but I'm not aware of anyone having written this for Linux<->Darwin. If you already have the source code, and it compiles in Linux, then you have a good chance of it also compiling under MacOS (modulo UI components, of course).

相比之下,Windows可执行文件可以有时可以在Linux下运行,因为Linux提供了用于Windows的PE格式的二进制格式加载程序,以及广泛的API实现(酒)。原则上这个想法也可以在其他平台上使用,但我不知道有人为 Linux<->Darwin 写过这个。如果您已经拥有源代码,并且它可以在 Linux 中编译,那么您也很有可能在 MacOS 下进行编译(当然是模 UI 组件)。

回答by ChrisJ

In general you can easily port a program across various Unix brands. However you need (at least) to recompile it on each platform.

通常,您可以轻松地跨各种 Unix 品牌移植程序。但是,您需要(至少)在每个平台上重新编译它。

Executables (binaries) are not usable on several platforms, because an executable is tightly coupled with the operating system's ABI (Application Binary Interface), i.e. the conventions of how an application communicates with the operating system.

可执行文件(二进制文件)在多个平台上不可用,因为可执行文件与操作系统的 ABI(应用程序二进制接口)紧密耦合,即应用程序如何与操作系统通信的约定。

For instance if your program prints a string onto the console using the POSIX writecall, the ABI specifies:

例如,如果您的程序使用 POSIXwrite调用在控制台上打印一个字符串,则 ABI 指定:

  • How a system call is done (Linux used to call the 0x80 software interrupt on x86, now it uses the specific sysenterinstruction)
  • The system call number
  • How are the function's arguments transmitted to the system
  • Any kind of alignment
  • ...
  • 系统调用是怎么做的(Linux以前在x86上调用0x80软件中断,现在用具体sysenter指令)
  • 系统调用号
  • 函数的参数如何传输到系统
  • 任何类型的对齐
  • ...

And this varies a lot across operating systems.

这在操作系统之间有很大差异。

Note however that in some cases there may be “ABI adapters” allowing to run binaries of one OS onto another OS. For instance Wineallows you to run Windows executables on various Unix flavors, NDISwrapperallows you to use Windows network drivers on Linux.

但是请注意,在某些情况下,可能会有“ABI 适配器”允许将一个操作系统的二进制文件运行到另一个操作系统上。例如,Wine允许您在各种 Unix 版本上运行 Windows 可执行文件,NDISwrapper允许您在 Linux 上使用 Windows 网络驱动程序。

回答by alexis

"bytecode" usually refers to code executed by a virtual machine (e.g. for java or python). C is compiled to machine code, which the CPU can execute directly. Machine language is hardware-specific so it it would be the same under any OS running on an intel chip (even under Windows), but the details of how the machine code is wrapped into an executable file, and how it is integrated with system calls and dynamically linked libraries are different from system to system.

“字节码”通常是指由虚拟机执行的代码(例如对于 java 或 python)。C被编译成机器码,CPU可以直接执行。机器语言是特定于硬件的,因此它在英特尔芯片上运行的任何操作系统下都是相同的(甚至在 Windows 下),但机器代码如何包装成可执行文件的细节,以及它如何与系统调用集成动态链接库因系统而异。

So no, you can't take compiled code and use it in a different OS. (However, there are "cross-compilers" that run on one OS but generate code that will run on another OS).

所以不,您不能采用编译后的代码并在不同的操作系统中使用它。(但是,有一些“交叉编译器”可以在一个操作系统上运行,但生成的代码可以在另一个操作系统上运行)。

回答by alexis

Well, maybe... but most probably not.

好吧,也许……但很可能不是。

But if it does, it's not "because both are UNIX" it's because:

但如果是这样,则不是“因为两者都是 UNIX”,而是因为:

  • Mac computers happen to use the same processor nowadays (this was very different in the past)
  • You happen to use a program that has no dependency on any library at all (very unlikely)
  • You happen to use the same runtime libraries
  • You happen to use a loader/binary format that is compatible with both.
  • Mac 电脑现在碰巧使用相同的处理器(这在过去非常不同)
  • 您碰巧使用了一个完全不依赖任何库的程序(不太可能)
  • 您碰巧使用相同的运行时库
  • 您碰巧使用了与两者兼容的加载程序/二进制格式。