Compilation 混合体系结构软件的可取性

在什么条件下，为不同体系结构编译的本机代码可以在同一操作系统上协作？究竟什么时候需要这种混合

比如说，32位代码可以在一个以64位为主的进程中运行，还是进程必须是纯的

我一直在开发一个Linux构建和打包系统。我的构建目标以体系结构（例如x86_64-gnu_linux）和变体（发行版、调试等）来区分，对于打包部分，我一直在简化的假设下操作，即没有包可以混合体系结构或依赖于为不同目标构建的代码。 这种简化到底让我损失了什么

---

假设您拥有所有源代码，并且可以为本机目标编译，那么是否需要一个混合体系结构包？

在Linux中，如果不使用任何黑客，32位共享库无法在64位进程中加载。相反，64位库不能在32位进程中加载。换句话说，过程是纯粹的；它们是32位或64位。虽然从技术上讲，设计一个支持混合进程的Linux操作系统是可能的，但我认为没有任何这样的Linux发行版

当需要互操作32位和64位二进制文件时，它们应该在不同的进程中运行，然后可以通过进程间通信（IPC）机制进行互操作

---

因此，如果您认为有可能在同一个包中有多个主可执行文件，那么有可能（尽管不常见）在同一个包中有不同位宽的二进制文件，这些二进制文件设计为通过IPC进行交互。但即使在这种情况下，也可能有一个主可执行文件（32位或64位）构成整个应用程序的起点。该可执行文件将负责启动其他32位或64位进程。包含所有这些可执行文件的包只能由主可执行文件的体系结构来描述，而不考虑包中任何其他可执行文件的目标体系结构。做这样的事情是合理的。

这个问题很有趣，但我担心这是离题的。@DavidPostill你认为它应该放在哪里？我猜，但我不完全确定。肯定是堆栈溢出。投票将此迁移到SO。虽然在单个进程中，从技术上讲，在长模式和兼容模式之间切换是可能的，但我认为没有人会这样做，因为没有可移植的方法。让一些线程使用常规的64位ABI，而让其他一些线程使用常规的64位ABI更合理。不过，对于这两个ABI，CPU都处于长模式。因为x32使用不同的库，所以这并不是很合理。