我想知道是否有人设法使用除gcc之外的其他编译器来编译Linux内核。或者，如果有人尝试过？问题似乎是愚蠢的或学术性的，但当我想到答案时出现了问题：Are C++ int operations atomic on the mips architecture
似乎某些操作的原子性不仅取决于cpu体系结构，还取决于使用的编译器。所以，我想知道在Linux世界中，除了gcc之外还有一些编译器存在。
答案 0 :(得分：12)
Linux显式依赖于某些gcc extensions，因此在这种情况下，任何其他编译器必须与所需的扩展兼容。
这不是“不”，因为单独的编译器供应商/开发人员当然不可能跟踪gcc的扩展，只是一个可以帮助您搜索的数据点。
答案 1 :(得分：10)
答案 2 :(得分：9)
LLVM开发人员正在尝试使用clang进行编译。 meta-bug on compiling the Linux kernel with clang有更多详细信息（dependency tree for that meta-bug显示似乎剩下的内容很少）。
答案 3 :(得分：8)
答案 4 :(得分：7)
烨。我做到了这一点。请参阅[cfe-dev] Clang builds a working Linux Kernel (Boots to RL5 with SMP, networking and X, self hosts)。
答案 5 :(得分：5)
IBM的编译器能够在某些Linux版本之前完成它，但我现在不确定，也不确定IBM如何按照指示优化内核。我所知道的是，他们得到了它。
由于Linux是自主托管（具有自己的libc）并且从一开始就使用gcc（和gcc交叉编译器）开发，因此使用其他任何东西都是愚蠢的。
我认为主要是，使用预处理器宏和指示优化是最好的障碍（甚至没有脱离天然气），因为GNU已经基本上写了上面的书，并扩展了它。除此之外，Linux调整其优化以使用gcc，例如，不要在内核中使用“volatile”而没有充分理由。使用内联并实际使编译器达成一致是另一项挑战。
Linus是第一个将GCC称为＆amp; *＃$ hole的人，这使得编译器更好。
这就是为什么我们有很好的GNU / Linux争论。
答案 6 :(得分：3)
很多很多年前，它实际上可能compile the kernel with g++，并且据我记得，部分动机是因为C ++有更强的类型检查，不一定要有g ++来生成目标文件。但正如尼尔巴特沃思所指出的那样，莱纳斯是not particular fond of C++，并且这种情况再次发生的可能性为零。
答案 7 :(得分：1)
EKOPath 4编译器，不是现在。但可能还有一些小补丁
答案 8 :(得分：1)
我现在正在使用Open64进行MIPS架构编译Linux内核，而其他一些人现在正在努力使Open64可以为X86 arch构建。现在内核可以部分运行，但仍然有Run fail errors。
然而，对于原子问题，至少我没有提出它。而且我认为这不是一个真正的问题。原因是：
Linux内核已经是源代码的集合，可以使用GCC成功构建，因此如果它无法构建它，或者构建的内核运行失败，它只是编译器的问题。
如果编译器想要成功构建Linux内核，它应该遵守GNU C扩展，这个扩展将清楚地描述原子操作是什么，所以这样的编译只需要生成代码根据这个扩展名。
答案 9 :(得分：-3)
我的非技术性猜测： Linux内核目前无法（ 2009 ）使用GNU编译器以外的任何编译器进行编译， gcc 。
我这样说是因为我听说理查德斯托曼有一定的信念，说 Linux 应该被称为 GNU / Linux ，因为内核是“只有1操作系统的一部分“我猜他如果内核不依赖于GNU就无法说出来（例如，一吨嵌入式设备在没有任何GNU软件的情况下运行Linux操作系统）。
正如我所说，只是一个猜测，让我知道我是不是错了......