假设您正在为一种名为 Foo 的新语言设计和编写编译器，它的优点之一是它特别适合实现编译器。一个经典的方法是用 C 编写编译器的第一个版本，然后用它用 Foo 编写第二个版本，之后它就可以自编译了。
这确实意味着您必须小心保留二进制文件的备份副本（与大多数程序相反，您只需保留源的备份副本）；一旦语言从第一个版本演变而来，如果您丢失了二进制文件的所有副本，您将无法编译当前版本。随它吧。
但假设它旨在同时支持 Linux 和 Windows。只要它实际上在两个平台上都运行，它可以在每个平台上自行编译，没问题。然而，假设您在一个平台上丢失了二进制文件（或有理由怀疑它已被攻击者破坏）；现在有一个问题。并且必须为每个受支持的平台保护二进制文件至少比我能接受的故障点多一个。
一种解决方案是让它成为一个交叉编译器，这样任何一个平台上的二进制文件都可以针对这两个平台。
这并不像听起来那么容易 - 虽然选择二进制输出格式没有问题，但每个平台都以 C 头文件的形式提供系统 API，这些头文件通常只存在于它们的本机平台上，例如没有保证代码stdio.h即使编译成 Linux 二进制格式，针对 Windows 编译也可以在 Linux 上运行。
也许这个问题可以通过将 Linux 头文件下载到 Windows 机器上并使用 Windows 二进制文件交叉编译 Linux 二进制文件来解决。
我缺少该解决方案是否有任何警告？
另一种解决方案可能是在 Python 中维护一个单独的最小引导编译器，它将 Foo 编译成可移植的 C，只接受主 Foo 编译器所需的语言子集并执行最小错误检查而不进行优化，目的是引导编译器因此将保持足够简单，以便在后续语言版本中维护它不会花费太多。
同样，我缺少该解决方案是否有任何警告？
过去人们用什么方法来解决这个问题？