有没有可能用gcc以外的东西编译Linux内核

我想知道是否有人设法用gcc编译Linux内核。 或者如果有人曾经尝试过? 问题似乎是愚蠢的或学术的,但是当我想到以下问题的时候,它就出现了: 在mips体系结构上,C ++ int操作是否primefaces化

看来,一些操作的primefaces性不仅取决于CPU架构,还取决于使用的编译器。 所以,我想知道在Linux世界中是否还存在除gcc以外的其他编译器。

Solutions Collecting From Web of "有没有可能用gcc以外的东西编译Linux内核"

Linux明确依赖于一些gcc扩展 ,所以在这种情况下,任何其他编译器都必须兼容所需的扩展。

这不是一个“否”,因为一个单独的编译器供应商/开发者跟踪gcc的扩展当然不是不可能的,只是一个可能帮助你搜索的数据点。

在某些时候tcc会处理和运行 linux内核源代码。 所以我猜这将是一个肯定的答案。

::在评论中提到了ephemient。::

已经有一些努力(和补丁 )用icc编译2.6内核的早期版本。

LLVM开发人员正试图用clang进行编译。 用clang编译Linux内核的元错误有更多的细节( 这个元错误的依赖关系树显示了剩下的很少)。

对。 我已经做到了 参见[cfe-dev] Clang构建一个可用的Linux内核(使用SMP,网络和X,自主机启动到RL5) 。

IBM的编译器能够在一些Linux版本之前做到这一点,但我现在还不确定,我也不确定IBM是如何按照指示优化内核的。 我所知道的是,他们把它建立起来了。

由于Linux是自我托管的(拥有自己的libc),并且从一开始就用gcc(和gcc交叉编译器)进行开发,所以使用其他任何东西都是愚蠢的。

我认为主要是,对于预处理器宏和优化指令的优化是最大的障碍(甚至没有脱离天然气),因为GNU已经基本上把这本书写在上面,并且扩展了它。 除此之外,Linux调整它的优化与gcc一起工作,例如,不要在内核中使用'volatile'来捕获,而没有一个很好的理由。 使用内联和实际上编译器认同是另一个挑战。

Linus是第一个调用GCC和*#$ hole的编译器。

这就是为什么我们有很棒的GNU / Linux的辩论。

很多很多很多年前,实际上有可能用g ++来编译内核 ,而据我所知,部分动机是因为C ++有更强的类型检查,不一定有g ++来生成目标文件。 但正如Neil Butterworth所指出的那样,Linus 并不是特别 喜欢C ++ ,而且这种可能性再次成为可能。

EKOPath 4编译器,不是现在。 但可能有一些小补丁

https://github.com/path64/repositories

http://www.pathscale.com/ekopath-compiler-suite

我现在正在使用Open64 for MIPS架构编译Linux内核,而其他一些人现在正在为使Open64可以为X86架构而努力。 现在内核可以部分运行,并且仍然有运行失败的错误。

但是对于原子问题,至少我还没有拿出来。 我不认为这确实是一个问题。原因是:

  1. Linux内核已经是源代码的集合,可以用GCC成功构建,所以只有编译器的问题,如果它不能建立,或者内核运行失败。

  2. 如果一个编译器想要成功构建Linux内核,它应该遵循GNU C扩展,而这个扩展将清楚地说明一个原子操作是什么,所以这样的编译只需要根据这个扩展生成代码。

我的非技术性猜测是: Linux内核目前不能用GNU编译器( gcc)以外的任何编译器进行编译。

我之所以这样说,是因为我听说Richard Stallman有一些信念,认为Linux应该被称为GNU / Linux,因为内核“只是操作系统的一部分”,而且我猜测他将无法如果内核不依赖于GNU(例如,一吨嵌入式设备在没有任何GNU软件的情况下运行Linux操作系统),请说出这一点。

正如我所说,只是一个猜测,让我知道如果我错了…