使用 Visual Studio 2010 构建 Linux 内核 [关闭]答案

【问题标题】：Building a Linux Kernel with Visual Studio 2010 [closed]使用 Visual Studio 2010 构建 Linux 内核 [关闭]
【发布时间】：2011-07-05 00:01:56
【问题描述】：

有人有关于如何使用 Visual Studio 2010 构建 Linux 内核的分步说明吗？

我试图直接寻找这个问题的解决方案，但没有任何乐趣。我发现了一些事情：

Linux 内核是使用 GNU C 编译器构建的，因此先决条件是构建 Windows GNU C 编译器，以便编译 Linux GNU C 编译器。我知道 GNU C 编译器源代码可从 GNU.org 获得，但有没有人真正使用 Microsoft Visual Studio 2010 C/C++ 编译器为 Windows 构建了 GNU C 编译器？
Linux GNU C 编译器制作完成后，我可以使用它来构建 Linux 内核，以及启动和运行 Linux 系统所需的任何其他基于 Linux 的软件。这是我从 www.linuxfromscratch.org 得到的

你们中的一些人可能想知道为什么我不为此简单地下载一个预编译的 GNU C 编译器？我工作的环境与任何外部网络完全分离。即使是运动鞋网也是不允许的。每一个软件都必须从源代码编译，并且这些源代码必须手动输入。它效率低下，但也是偏执安全的。（别问，我不是老大……）

无论如何，我们正在考虑推出内部 Linux 机器，但我们从 Windows 7 和 Visual Studio 2010 开始。有人可以建议我们如何将所有重新键入的源代码转换为工作 GNU Windows 的 C 编译器？也适用于 Linux？

感谢您的建议！

【问题讨论】：

只要 Visual Studio 是一个仅限 Windows 的软件，我真的怀疑是否存在对您想要实现的目标的任何支持。用于 linux 内核的工具链非常不同，除非您编写大量脚本，否则可能无法与 Visual Studio 互操作。
如果你设法输入 GCC 的源代码，在 VS 2010 中编译它，然后输入 Linux 内核源代码并编译它，请制作一个博客或电影或其他记录此内容的东西。我真的很想看看。
您的环境对安全性如此偏执，但使用的是 Windows？这看起来……很奇怪。
@Billy：不是想发动一场火焰战争……我只是觉得这很有趣。就像有人说“每个软件都必须从源代码编译”，但运行编译器的东西（以及编译器本身）甚至没有可用的源代码。
您比 4 月 1 日晚了 3 个月零 1 天。

标签： c linux visual-studio

【解决方案1】：

我认为 Ken Thompson 的 "Reflections on Trusting Trust" 很好地解释了这个想法是多么徒劳且不够偏执。

你不能相信您没有完全创建的代码你自己。（特别是来自的代码雇用像我这样的人的公司。）没有多少源代码级别的验证否则审查将保护您免受使用不受信任的代码。

如果您没有自己从源代码编译，您怎么知道您将用于构建 GCC 的编译器是安全的？那你使用的编译器呢？

您需要手动输入 machine 代码以供编译器引导您的 100% 安全环境。只有这样，您才能信任已编译的源代码，无论您是否手动输入。

【讨论】：

而且他也不应该信任硬件供应商。为好文章 +1。
在后斯诺登时代，“你不能相信不是你完全自己创造的代码。（尤其是那些雇佣像我这样的人的公司的代码。）”这样的评论让我很好奇。
你不能相信不是你自己制造的计算机芯片，或者不是你自己蚀刻和焊接的电路设计。不信任和有用的方法是有限度的。

【解决方案2】：

事实：你需要 gcc 来编译内核。

事实：您需要内核源代码来编译内核。

一旦你有了这两个，你就可以引导一个工作内核，针对你想要的任何平台。

您可以在任何您希望的平台上完成所有这些操作。例如，您可以在 Windows 上构建 Linux 内核。您可以在 Windows 上为 ARM 或 PPC 轻松构建 Linux 内核。

但您必须拥有内核源代码和 gcc 编译器才能开始使用。

内核源代码和 gcc 源代码都依赖于数以千计的头文件和 .c 文件。手动键入它们根本不实用。

恕我直言...

【讨论】：

哦，不，我很想看到有人手动输入整个 linux 内核、libc 和 gcc 以及他们所依赖的所有东西——这可能是地狱的第十圈：D
@Voo: 然后调试所有的打字错误！并及时更新所有安全修复程序。哈哈哈哈哈哈
你不需要 GCC。 clang 也可以编译一个工作的 Linux 内核。
事实：你不知道你在说什么。
sysprogs.com/VisualKernel

【解决方案3】：

如果您要构建内核，请使用 Linux 发行版。在 Windows 下构建一个没有意义。即使您要制作自己的 Linux，仍然为此使用 Linux。

你总是可以尝试 cygwin，但我怀疑这对你有什么好处，即使你安装了所有的包。

【讨论】：

【解决方案4】：

Fabrice Bellards tcc 能够编译 Linux。它是如此之小，您可能可以在 Visual C++ 中编译它（或修改直到它工作）。你也可以试试他的qemu来模拟电脑。

最近他甚至用 Javascript 实现了一个 x86 虚拟机，所以你可以在浏览器中运行一切。

【讨论】：

【解决方案5】：

即使是运动鞋网也是不允许的。每一个软件都必须从源代码编译，并且这些源代码必须手动输入。它效率低下，但也很安全。

告诉你的老板，让某人手动输入源代码只会引发错误。如果他们想要 Linux 机器，那么他们将不得不使用 Linux 的源代码。你们也没有手动输入所有 Windows 7 源代码，是吗？内核大约有 13.5 百万行源代码。如果与打字错误相关的错误，您将无法在不引起大量错误的情况下全部输入，这不太安全而不是仅仅复制源代码。

你的老板需要明白即使只是输入那么多代码，即使这个人是 100% 完美的打字员，也需要年。

【讨论】：

我不认为打字引起的错误将是他们最大的问题。我认为当前的内核大约有 1500 万个 LOC（150 万个或多或少重要吗？）——即使让十几个人手动输入这些代码也需要几个月的时间！
我同意。我只是指出这一点，因为操作员正在谈论安全性，而拼写错误可能会导致重大安全问题。
您始终可以将手动输入的代码导出到安全墙之外，并将其与已知正确的代码进行比较...
而且，手动输入代码仍然是sneaker-net。一个奇怪的、疯狂的运动鞋网，但仍然是一个运动鞋网 :) 我还想知道打印出内核源代码需要多少纸张。
那么重新输入的意义何在？大概它是从来自将被偷窥的文件的列表中键入的。如果您的安全系统无法安全地读取纯文本源文件（在最坏的情况下，编写一个简单、易于验证的过滤器来验证它们只是有效的 C 源代码），那么我不得不说希望不大......

【解决方案6】：

输入整个代码是指复制/重新输入每一行代码？

请允许我问一下，这将与原始代码有何不同？

如果您只是复制，那么您没有修复错误或检查可能的漏洞。你是？我宁愿花相应的时间审查实际代码并报告或修复您偶尔发现的问题。

【讨论】：

同意。输入代码并不比下载代码更安全。由于您需要从 some 源中复制它。如果您决定不信任该来源，输入它会获得什么？您只是使用低带宽（和高错误率）的手段来制作副本。如果您决定信任来源，只需使用下载的来源并检查发布者的 md5。

【解决方案7】：

好的。这几乎是不可能的。

你是怎么做到的：

下载virtualbox
下载Ubuntu iso
安装 Virtualbox
创建并安装 Ubuntu 虚拟机
在那台虚拟机的终端上：

sudo apt-get build-essential
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.39.2.tar.bz2
tar vxjf linux-2.6.39.2.tar.bz2
cd linux-2.6.39.2
make menuconfig ; make

或者类似的...

【讨论】：

但是他必须输入 ubuntu ISO 的所有二进制字符，并输入 VirtualBox 的所有源代码......这只会让这个过程花费更长的时间！ :)
哦，哈哈，现在我正确地阅读了这个问题...... w t f

【解决方案8】：

假设这个问题不是喷子（这可能吗？）...也许您正计划将源代码 OCR 到您的系统中，就像 PGP 过去如何绕过加密软件导出限制一样。

但我认为使用 MSVC 构建 GCC 不会有任何运气，无论有多少猴子可能正在输入源代码。来自http://gcc.gnu.org/install/specific.html：

GCC 将在 Cygwin 下构建，无需修改；它不是使用 Microsoft 的 C++ 编译器构建的，也没有计划这样做。

当然，如果您确实设法在您提供的条件下将 GCC 安装到系统中，并且您以某种方式获得了 Linux 内核源代码，我认为您将在基于 Windows 的 GCC 下交叉编译 Linux 时遇到困难交叉编译器。如果不出意外，Linux 源代码树和构建环境至少在一定程度上依赖于 Unix 文件系统的大小写敏感特性（即，它们依赖于 fielname 仅在字符大小写上不同的事实）。 Windows 不能很好地处理仅大小写不同的文件名（我认为可以通过某种方式配置 NTFS 以支持它们，但 Win32 子系统几乎肯定会被彻底混淆）。

我确定还有其他障碍。

【讨论】：