［原创］功能单一，体积小巧的LFS完整版（5M大小的Apache服务器）

晨想

--enable-static-nss
就是那个 /etc/nsswitch.conf 的东西，应该没什么影响的吧？不过我不确定。感觉似乎没什么联系。。

第二个，静态编译的话，用的是主机的库，如果还是按照LFS的方式做一个系统出来，感觉太麻烦了。。。活活。。。

redkaoliang

Post by youbest

如果直接开始，那么编译出来的bin代码将会使用host系统中的库，这是必然的。

用host系统采用静态编译出的bin代码，所需的相应的库文件都静态连接进了bin代码，那么这个bin代码应该就可以独立运行，不与host的库有联系了吧

晨想

但是还是从host出来的。。。。

redkaoliang

我从http://www.gnu.org/software/libc/FAQ.html#s-1找到一个FAQ，说明静态编译的bin文件也有可能要动态连接某些共享库
FAQ2.22. Even statically linked programs need some shared libraries which is not acceptable for me. What can I do?
{AJ} NSS (for details just type `info libc "Name Service Switch"') won't work properly without shared libraries. NSS allows using different services (e.g. NIS, files, db, hesiod) by just changing one configuration file (/etc/nsswitch.conf) without relinking any programs. The only disadvantage is that now static libraries need to access shared libraries. This is handled transparently by the GNU C library.
A solution is to configure glibc with --enable-static-nss. In this case you can create a static binary that will use only the services dns and files (change /etc/nsswitch.conf for this). You need to link explicitly against all these services. For example:


  gcc -static test-netdb.c -o test-netdb \
    -Wl,--start-group -lc -lnss_files -lnss_dns -lresolv -Wl,--end-group

The problem with this approach is that you've got to link every static program that uses NSS routines with all those libraries.
{UD} In fact, one cannot say anymore that a libc compiled with this option is using NSS. There is no switch anymore. Therefore it is *highly* recommended *not* to use --enable-static-nss since this makes the behaviour of the programs on the system inconsistent.

good02xaut

这样做和LFS有什么关系呢？
功能单一，体积小巧的LFS完整版（5M大小的Apache服务器）
命名不合理，会把大家带到迷途。
[color="Red"]功能单一，体积小巧的linux-apache完整版（5M大小的Apache服务器）

在任何一个floopy-linux上安装个apache应该都不会很大的。
大家可能刚刚从LFS过程出来，没有做过floopy-linux,没有用过busybox。对任何可以启动的内核都比较感兴趣，但LFS不是为了做个可以启动的内核！

linux-kernel  <1.5M
busybox(shell,httpd)<1M,静态编译
这二者加起来不到2.5M。也称的上体积小巧的linux-http服务器完整版，不过没有意义，至少和LFS是风马牛不相及！

[color="red"]能称的上是LFS－linux，必须有第5章的所有软件。
不然，在你的linux上make 个mpg123出来看看？不行吧。
不行就不能称LFS，小不是LFS，能boot也不是LFS。

我贴的“另一种安装LFS”，之所以失败，就是我的Linux上make不出来任何src！

玩LFS，就是玩的toolchain，玩的依赖关系。任何没有make-toolchain的linux都不能和LFS沾亲。ubuntn就是个典型，居然连GCC都没有。

或许是大家对LFS理解的角度不同，仁者见仁，智者见智！
单从字面上，一个没有toolchain的linux还是不要成为LFS比较好：）

晨想

LFS 是教你怎么做系统，不是教你怎么按部就班，只要一个系统出来了，叫 LFS 我觉得并不离题。

引用 LFS book 的话：

This Linux From Scratch book provides readers with the background and instruction to design and build custom Linux systems. This book highlights the Linux from Scratch project and the benefits of using this system. Users can dictate all aspects of their system, including directory layout, script setup, and security. The resulting system will be compiled completely from the source code, and the user will be able to specify where, why, and how programs are installed. This book allows readers to fully customize Linux systems to their own needs and allows users more control over their system.

简单的说，按照某些需求，自己做出来的，都可以说是 LFS 。：）。

Another benefit of LFS is the ability to create a very compact Linux system. When installing a regular distribution, one is often forced to include several programs which are probably never used. These programs waste disk space, or worse, CPU cycles. It is not difficult to build an LFS system of less than 100 megabytes (MB), which is substantially smaller than the majority of existing installations. Does this still sound like a lot of space? A few of us have been working on creating a very small embedded LFS system. We successfully built a system that was specialized to run the Apache web server with approximately 8MB of disk space used. Further stripping could bring this down to 5 MB or less. Try that with a regular distribution! This is only one of the many benefits of designing your own Linux implementation.

另一段。

兄弟仔细读读。

code_tin

做实事才是最重要的
站着说话始终是不腰疼得

good02xaut

可不是基于源码安装，还有意义吗？
在主机把target上的bin做出来，这和我们用的rpm无异啊。
在主机上做个toolchain是可以理解的，其他的如果还都依赖于主机就没意义了。

楼上的，我说话可是很严谨的，都会做理论分析和实际验证的。
分析错了，可以认错
做错了，也可以认错

唯有错了，一开始就不承认的，才是不腰疼啊

技术交流，技术分歧都是可以理解，那些不是技术范畴内的，毫无意义！

youbest

Post by good02xaut

玩LFS，就是玩的toolchain，玩的依赖关系。任何没有make-toolchain的linux都不能和LFS沾亲。ubuntn就是个典型，居然连GCC都没有。

LFS=toolchain还是LFS=gcc
toolchain只不过是一个中间步骤而已,而且我好象在文章里面也建立了,至于GCC,我觉得系统里面没有GCC没什么不可以,一个系统不一定非要编译程序才行呀?

我没仔细考虑过标题的问题,之所以用了LFS,主要是因为基本上还是LFS的方法,只是改了一些地方,另一个也是想沾点LFS的光,至于"完整版"这个主要是针对之前的另外一篇文章相对而言的.谢谢你的意见.

youbest

Post by good02xaut
可不是基于源码安装，还有意义吗？
在主机把target上的bin做出来，这和我们用的rpm无异啊。
在主机上做个toolchain是可以理解的，其他的如果还都依赖于主机就没意义了。

楼上的，我说话可是很严谨的，都会做理论分析和实际验证的。
分析错了，可以认错
做错了，也可以认错

唯有错了，一开始就不承认的，才是不腰疼啊

技术交流，技术分歧都是可以理解，那些不是技术范畴内的，毫无意义！

谢谢你提出的问题,没有争论就没有进步

不过也希望你能仔细的看过我的文章后再下定论,我的文章中已经提到过可以有两种分支来完成这个系统,其中一个是在建立起完整的系统后在进行apache的编译,另外一种只是为了能够快速的完成而走了捷径,为了篇幅考虑我才以后面一种方式来讲述,因为两种方法到后面基本是一样的,为了和LFS上有所区别所以就只选了后面一种方式.