当前位置：首页 → 问答吧 → 关于lfs6.3的总结和疑问

关于lfs6.3的总结和疑问

时间：2009-12-16

来源：互联网

I>.解决为什么可以编译出一个与host机器没有依赖的临时环境.我觉得4个概念要弄清楚
1.lfs6.3第6章编译glibc中说"The Glibc build system is self-contained",也就是说glibc只需要一些工具(binutil,gcc....)，而它本身不需要运行,也不需要什么依赖.
2.第5章gcc-pass2中:"Patching now rather than adjusting the specs file after installation ensures that the new dynamic linker is used during the actual build of GCC"
这句话就是说,[gcc本身是自编译的]打了patch之后,gcc编译的过程中将自己连接到我们新的glibc.
到此为止,glibc,gcc已经是相互依赖,而且都是与host机器脱离.gcc-pass2以后编译的包也就依赖新的glibc
3.为什么有binutil-pass1,gcc-pass1,可能是新的系统需要新版本的binutil和gcc,而且有利于和host机器脱离关系,
更有利于编译后面的包,因为我们可以在编译binutil和gcc的时候就能指定选项(头文件,库路径....),不用因为使用host机器的binutil个gcc,
而每次都需要指定特定的编译选项。
4.为什么编译第6章.
我觉得是因为路径的缘故.因为第5章,我们不嫩指定--prefix=/usr,而第6章我们需要的命令,库又不能在/tools下.所以从新编译,实现的像标准linux那样

我的疑问::::::
如1所说glibc是自给自足的.可是在第6章,没有调整gcc工具链的时候,先编译的glibc.
这样的话glibc的库肯定可以运行,可是和glibc一起安装的命令(catchsegv, gencat, getconf, getent, iconv, iconvconfig, ldconfig, ldd....).
这些命令应该指向/tools/lib.可是实际上不是.这些命令都指向/lib.我不知道为什么？？？？？？？
如果glibc自给自足的话，那也太智能了!!!!!!
大家给解答

作者: yueluck 发布时间: 2009-12-16

在 LFS 环境下，您不容易理解"自包含"，如果进行 CLFS，您会清楚许多：
自包含是指用裸编译器可以编译；裸编译器是没有任何库支持的编译器，如 CLFS 中 gcc-pass1。
典型的自包含的例子是 linux-kernel freebsd-kernel 及各种 libc，原因很简单，它们是最基本的东东，编译时不能依赖任何其它库。

第二个问题原因很简单：避免新的工具链访问到宿主资源。

第三个问题是为了避免原宿主工具链对新系统造成影响，如 ABI 方面的影响。

第四个问题只是 LFS 为了满足一般 GNU/Linux 系统目录习惯结构，只是个风格问题，同时也进一步保证系统纯度。

作者: 聚焦深空发布时间: 2009-12-16

CLFS???先去看看

作者: yueluck 发布时间: 2009-12-16

引用:

作者: 聚焦深空

在 LFS 环境下，您不容易理解"自包含"，如果进行 CLFS，您会清楚许多：
自包含是指用裸编译器可以编译；裸编译器是没有任何库支持的编译器，如 CLFS 中 gcc-pass1。

“裸编译器”这个说法不对头，所有的编译器链接的时候都要找链接库，除非人为指定不要库

“自包含”应该这样理解：编译器链接的时候不需要到外部去找库，软件本身就包含有库，这个库编译好了以后，软件中的其它库和执行文件直接链接到这个库上，这样整个软件完全不依赖外部的库。

作者: 5000 发布时间: 2009-12-16

楼上，“裸编译器” 是偶个人专有名词，不许乱用，要抽版权费用的，拿钱来。

这个名词其实不是偶第一个用起来的，但在中文圈偶可能是第一个。
是个非常形象的说法，意思也贴切，就如偶前面解释的。
如果您没有 c 基础，不会明白有多么贴切。

作者: 聚焦深空发布时间: 2009-12-17

引用:

作者: 5000

“自包含”应该这样理解：编译器链接的时候不需要到外部去找库，软件本身就包含有库，这个库编译好了以后，软件中的其它库和执行文件直接链接到这个库上，这样整个软件完全不依赖外部的库。

对自包含的内核，您也要这么解释？

作者: 聚焦深空发布时间: 2009-12-17

内核级代码本来就不会和用户级代码捞在一起，也就不会链接到宿主机的库上，本身就自成一体，无所谓自包含一说，您不知道吗？

作者: 5000 发布时间: 2009-12-17

引用:

作者: 聚焦深空

原来是大师自创的术语啊，偶等小民可用不起，也用不惯

裸X编译器，听着就别扭，还是留您自个用吧

作者: 5000 发布时间: 2009-12-17

如果某人没事干，写一个用户空间的软件，不使用任何库，不使用任何系统调用，按您标准也不算自包含的？
没有多少人这么做，是因为不经济。
库只是特殊形式的代码。

内核只是特殊些的软件，一般会使用些特殊的硬件特性，对编译器来说所有代码是一样的，没有高低贵贱。

请全面考虑问题。

作者: 聚焦深空发布时间: 2009-12-17

我的这个解释只针对LZ的问题所作，您不必死钻牛角尖，况且您所举的特例在现实中根本不存在！

库的概念仅存在于用户空间，而您说linux-kernel freebsd-kernel不能依赖任何其它库，这不是很可笑吗？它能依赖得了吗？！还搬出所谓的原创词语去糊弄人家，这我就看不下去了！

作者: 5000 发布时间: 2009-12-17

"裸编译器"的说法偶是多年前看到的，原始出处已不可考，但其已经算是一个专业术语，有广泛使用，如 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=$PATH:$PREFIX/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 可简单实现。

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

作者: 聚焦深空发布时间: 2009-12-18

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

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

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

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

作者: 5000 发布时间: 2009-12-19

引用:

作者: 聚焦深空

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

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

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

上传的图像

os.png (9.3 KB, 10 次查看)

作者: 5000 发布时间: 2009-12-19

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

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

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

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

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

作者: 聚焦深空发布时间: 2009-12-19

引用:

作者: 聚焦深空

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

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

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

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

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

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

作者: 5000 发布时间: 2009-12-20

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

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

作者: 飞龙在天发布时间: 2009-12-20

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

作者: moolee 发布时间: 2009-12-21

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

作者: yueluck 发布时间: 2009-12-22

引用:

作者: yueluck

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

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

引用:

作者: yueluck

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

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

引用:

作者: yueluck

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

这是您的自由。

作者: 聚焦深空发布时间: 2009-12-24