【问题标题】:Why are Universal Binaries/FatElf not part of Linux kernel? [closed]为什么 Universal Binaries/FatElf 不是 Linux 内核的一部分? [关闭]
【发布时间】:2012-04-16 01:42:13
【问题描述】:

Apple 的通用二进制文件概念允许轻松传送包含 32 位和 64 位版本的二进制文件的单个文件。

虽然这在使用 FatElf 的 Linux 中是可能的,但 FatElf 和通用二进制文件的概念在默认情况下并未在内核中烘焙?

这背后的原因是什么?为什么内核开发人员认为在 linux 上拥有通用二进制文件是个坏主意?

更新
我不是在寻找讨论。假设通用二进制文件不是主要 linux 内核的一部分。我只是在问它背后的原因。

【问题讨论】:

  • “为什么内核开发人员认为在 linux 上拥有通用二进制文件是个坏主意?” [需要引用]
  • 这个问题完全不适合 SO。这是一个讨论的呼吁,并且在FAQ 中特别提到在这里不合适。这是一个问答网站,不是讨论组或聊天室。投票结束,因为没有建设性。
  • 好吧,那么应该在哪个 stackexchange 网站上发布?
  • 也就是说,有一个类似主题的问题,已经被允许在 SO stackoverflow.com/questions/520068/…
  • Ignacio:环顾四周,fatelf 提案似乎自 2009 年以来就已经存在,但仍未实施,所以我认为内核开发人员出于某种原因不想要它。是的,我没有引文。但这就是我打开这个帖子的目的。要么找到有解释的引文,要么找到知情人士对此的合理回答。

标签: linux universal-binary


【解决方案1】:

鉴于通用二进制文件不是主要 linux 内核的一部分。我只是在问它背后的原因。

胖二进制文件是 32 位或 64 位系统所需的两倍。

既然提供两个单独的二进制文件和提供一个单独的二进制文件一样容易,为什么我要在我的系统上携带额外的脂肪,或者为什么要强迫最终用户下载两倍于他们的脂肪需要吗?

认为 MacOS 选择使用胖二进制文件的原因是他们不希望最终用户了解他们是在 PPC Mac 还是 Intel Mac 上运行。

Linux 用户在理解他们是在 32 位还是 64 位系统上运行时似乎没有问题。

【讨论】:

  • 为了避免多余的脂肪,你可以编译成单一的中间格式,然后可以翻译成本机。 PNaCl 这样做developers.google.com/native-client/pnacl-preview/…
  • @techtonik 问题是关于 Linux kernel。我很难想象 PNaCl 会支持构建内核——当然这不是当前 PNaCl 开发人员的目标。
  • PNaCl 只是 32 位和 64 位系统的常见二进制格式的一个例子,它的大小是 32 位二进制的两倍,因此没有额外的脂肪。
猜你喜欢
  • 2010-09-06
  • 1970-01-01
  • 2021-09-20
  • 2013-05-21
  • 2012-01-23
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多