关于lfs6.3的总结和疑问

聚焦深空

"裸编译器"的说法偶是多年前看到的，原始出处已不可考，但其已经算是一个专业术语，有广泛使用，如 http://wiki.osdev.org/GCC_Cross-Compiler 中有段：

  gcc

Now, you can build GCC. (Use v3.3 or later - v3.2.x has a bug with internal __malloc declarations resulting in an error during compilation. This could be fixed by patching four occurrences in three different source files, but I lost the diff output and am not in a mind of re-checking. ;-) )

cd /usr/src/build-gcc
export PATH=$PATHPREFIX/bin
../gcc-x.x.x/configure --target=$TARGET --prefix=$PREFIX --disable-nls \
    --enable-languages=c,c++ --without-headers
make all-gcc
make install-gcc

The path has to be extended since GCC needs the binutils we built earlier at some point of the build process. You might want to add these extensions to your $PATH permanently, so you won't have to use fully qualified path names every time you call your cross-compiler.
--disable-nls is the same as for binutils above.
--without-headers tells GCC not to rely on any C library (standard or runtime) being present for the target.
--enable-languages tells GCC not to compile all the other language frontends it supports, but only C (and optionally C++).
If you are compiling GCC <= 3.3.x, you need --with-newlib as additional parameter. Those older versions have a known bug that keeps --without-headers from working correctly. Additionally setting --with-newlib is a workaround for that bug.
  Summary

Now you have a "naked" cross-compiler. It does not have access to a C library or C runtime yet, so you cannot use any of the standard includes or create runable binaries. But it is quite sufficient to compile your self-made kernel.

前面一个玩笑就能激起您那么高怒气。

内核一样有库，只是无法像用户空间库那样存在，您自己看看 linux-kernel 中的 lib 目录。

  一个用户空间的软件，不使用任何库，不使用任何系统调用，特例存在，并且偶自己早些年真的那么玩过，为了看看绕过 内核 和 libc 能做什么。
您如果接触嵌入式开发用的板子，更容易理解，简单点，一般板子上有些 LED，控制用的管脚一般直接编址到内存特定地址特定位，对内存特定地址操作即可完成对 LED 的控制，用 c 可简单实现。

全面考虑问题 不是 钻牛角。

5000

hoho,连大段洋文都搬出来了，想唬谁呢

还“已经算是一个专业术语，有广泛使用”呢，洋人不过是随口一说，您就当宝似的拿来这里显摆，各位搜索一下"naked" cross-compiler就知道怎么回事！

现代多用户、多任务操作系统使用共享库技术，用户进程/程序使用同一组代码的，只需在内存/硬盘保留一个拷贝，用户进程的调度、切换由内核完成，用户操作硬件也需通过内核完成，因而有内核空间、用户空间之分。这就是说共享库、内核/用户空间这些概念仅存在于多用户、多任务操作系统中，而您硬要把一个无操作系统、直接操作硬件的嵌入式软件说成是不依赖任何库的用户空间软件，实在太荒谬可笑了，照你这个思路，DOS下很多软件也是“自包含”的哦

您不是在钻牛角尖就是在滥用概念

5000

Post by 聚焦深空;2056874

内核一样有库，只是无法像用户空间库那样存在

这话也就只有你才敢说，内核可以是模块化设计，但没人会把内核模块叫作库，一个名为lib的目录，你就认为里面放的是库文件？您的库的概念也太宽泛了

我看你该补补操作系统的课了，好好看看这张操作系统的结构图，看看kernel在哪里，library在哪里

聚焦深空

前面不是说了么，内核是特殊情况。
linux-kernel lib 目录下主要是内核空间使用的一些公共代码，提供如类似用户空间的　memset()　一类的函数，按偶的理解，属于库。
如果您认为只有用户空间二进制的　*.so *.a *.la 文件才算库，那是您的自由，对偶来说这些是二进制库文件。

说的是内核，您拿操作系统结构来偷换概念，不是很好笑么。

仇视洋文，并抵制洋文，只能说明您心胸狭隘。

人家对"裸编译器"使用范围是夸张些，无恶意，您不接受，笑笑不就够了。

不同人有不同看法观点，本是正常的，看您一直想努力说明只有自己正确，有必要么。

5000

Post by 聚焦深空;2057099

人家对"裸编译器"使用范围是夸张些，无恶意，您不接受，笑笑不就够了。

不同人有不同看法观点，本是正常的，看您一直想努力说明只有自己正确，有必要么。

你一直在糊弄我们，看到糊弄不下去了，就想和稀泥蒙混过去，真是死鸭子嘴硬

坛子里的某些人啊，基本功不扎实，却热衷于到新手的帖子里充高手，故弄玄虚地显摆一些“专业术语”，实际上是在传播些似是而非的“知识”

“内核一样有库”
“典型的自包含的例子是 linux-kernel freebsd-kernel ”
嵌入式软件是“自包含”的用户空间的软件
“"裸编译器"已经算是一个专业术语，有广泛使用”

这些非主流观点谁愿意接受就接受去吧

飞龙在天

在内存、硬盘都已经足够大的今天，库应该到了要消失的阶段了。或者是建立自給自足的库。

每个软件都能不依赖第三者而独立运行，不需要解决这个依赖那个依赖的问题，拿过来就能用，那该是多么畅快的事情。

moolee

表喷我，我是来感受中国历史的广度和海水的深度的，看来大家都给冻住了，呵呵

yueluck

1.gcc需要glibc库.
至于裸编译器真的没听过.除非要把它静态编译
2.glibc的目的就是使 用户层可以使用内核的接口，
ko文件是内核,可以直接使用内核api，也可以使用glibc,但和ld-linux.so以及 动态库 无关，
3.比较支持 自包含的意思是---不依赖其他任何库.因为glibc本身是so,a自己根本不运行

聚焦深空

Post by yueluck;2058146
1.gcc需要glibc库.
至于裸编译器真的没听过.除非要把它静态编译

动态连接的 gcc 需要连接到 libc，但不一定是 glibc。
正常情况下，只有建立交叉编译器时，才能遇到 裸编译器，即 CLFS 中的 gcc-pass1。
可以人工建立 裸编译器，把正常 gcc 编译器搜索路径统统去掉即可，相当于把"库"做的衣服脱掉：
一个可以修改 specs；
一个可以使用命令行。
真实例子：编译 glibc 时，可以打开 Makefile 看 glibc 是怎么用命令行调用 裸编译器。

Post by yueluck;2058146
  2.glibc的目的就是使 用户层可以使用内核的接口，
ko文件是内核,可以直接使用内核api，也可以使用glibc,但和ld-linux.so以及 动态库 无关，

红色部分错误。
内核空间 与 用户空间 依靠硬件特性严格分离，您可以认为是基于安全考虑，内核空间权限在 root 用户之上，这也是为什么有那么多 rootkit 存在的根本原因。
常规情况，内核空间 和 用户空间 交流靠系统调用、设备文件，中介是 libc。
绕过 libc 是可行的，只是不经济，如前面提到的。

Post by yueluck;2058146
  3.比较支持 自包含的意思是---不依赖其他任何库.因为glibc本身是so,a自己根本不运行

这是您的自由。