求教：如何建立一个静态的LFS？

飞龙在天

鉴于这几天头痛于Linux软件包之间错综复杂的依赖关系
想建立一个纯静态的LFS系统，编译好的软件打包，以后放到任意的Linux系统中都能运行。
对一个最简单的htop程序用 make LDFLAGS="-all-static"来建立，报错。
是不是系统没一个软件包都需要静态化，才能把大型的软件进行静态编译？有做个这方面的前辈给指点下。
我的主要目标就是建立静态的xorg、qt、kde、xfce等大型的桌面软件。单独放到一个目录下，打包。拿到别的系统上直接用。可不可行？

飞龙在天

还有个问题，比如htop
[root@wdzx htop-0.6.5]# ldd htop
        linux-gate.so.1 =>  (0xb7fba000)
        libm.so.6 => /lib/libm.so.6 (0x0037d000)
        libncurses.so.5 => /usr/lib/libncurses.so.5 (0x006c4000)
        libc.so.6 => /lib/libc.so.6 (0x00235000)
        /lib/ld-linux.so.2 (0x00213000)
        libdl.so.2 => /lib/libdl.so.2 (0x00377000)
需要用到   /lib/libm.so.6中的函数，而
[root@wdzx htop-0.6.5]# ldd  /lib/libm.so.6
        /lib/ld-linux.so.2 (0x00213000)
        linux-gate.so.1 =>  (0xb7fa0000)
        libc.so.6 => /lib/libc.so.6 (0x00235000)
又链到其他库中，是不是因为这样的原因才导致htop无法静态化？

如果Linux系统中的各种基础库都是静态化，就能实现软件全静态？
最好是能有选择性的进行静态化，如glib之类的不需要静态进来。

poet

选择性静态化的前提是各个系统都是一样的。例如windows，每个人的系统都是XP，或者是7，winapi基础库的版本都是一致的。当每个人都具有一个共同的基础系统时，二进制发行和选择性静态发行就成为了可能。

Linux 的世界里，每个人机器上的 libc版本gtk版本kernel版本都不同。你想要选择性静态化，基本不可能。因为基础库不可假设。在 debian testing上编译一个基于 gtk 的程序，你会发现他们依赖的glib会依赖 glibc 2.9，你把他们拿到 debian stable 上面去运行，然后就运行不了了说glibc版本太低。如果你把 debian stable 的 glibc 替换成2.9，会发现系统无法启动了。最后你发现你必须把 libc 和 libm 也静态化才行。当你编译测试了足够多的软件在足够多不同的linux发行版中运行时，会发现你基本上需要静态化全部的库才能够实现。——甚至你可能需要附带一个 ld_linux。

完全性静态化是否可能呢？可能，只要你不介意几乎每个程序的内存占用都扩大了五六倍，那么请把整个系统中所有的库都静态化吧。。。

你要真想到处跑你的程序，不如直接在 U 盘上安装一个 linux。

飞龙在天

Post by poet;2074345

Linux 的世界里，每个人机器上的 libc版本gtk版本kernel版本都不同。你想要选择性静态化，基本不可能。因为基础库不可假设。

将libc、gtk也静态进来。

聚焦深空

楼主，想法可行，但不实用。
静态链接程序过多，会占用过多的存储空间，故不实用。
动态链接越来越流行，静态链接应用范围越来越小，现在主要用于一些特殊场合，如急救、测试、入侵。
前些年 3DO Heros3 linux demo 即静态链接方式。

使用 autotools 配置的软件，一般可使用 --enable-static 指定静态链接。
一些不标准的软件包可能需要修改 Makefile。

甭受楼上 poet 误导：静态链接程序只受硬件、内核限制，和发行版关系不大。

PS: 其实，如果不准备建立静态链接程序，可删除系统中所有 lib*.a 以进一步缩小系统占用空间。

wsw

多年发布Linux下二进制程序的人忠告：解决依赖问题，静态不是好办法。

飞龙在天

Post by 聚焦深空;2074368

静态链接程序过多，会占用过多的存储空间，故不实用。

今日的硬盘组装机新盘最少也得250G吧，存储空间应该不是问题了。做静态程序的想法主要是解决软件包的依赖问题。

Post by 聚焦深空;2074368

使用 autotools 配置的软件，一般可使用 --enable-static 指定静态链接。
一些不标准的软件包可能需要修改 Makefile。

谢谢。我用make --all-static没编译成功htop。
我试下，看看静、动到底有多大的尺寸差异。3倍左右的扩大应该在接受范围之内

聚焦深空

简单解释如下：
静态连接程序，需要把所有用到的库函数连接到可执行文件。相当于"拷贝"。N 个程序需要 N 个拷贝，修改库必须重新编译 N 个程序。
动态连接程序，只需要把所有用到的库函数地址写入可执行文件。相当于"软连接"。N 个程序只需要 1 个拷贝，修改库不改接口时只需要编译动态库。

早期 *nix-like 系统使用静态连接方式。
动态连接方式发明时，大家比较两种方式占用存储空间、维护难度，自然而然抛弃静态连接方式。
您可以找 a.out ELF 相关资料读读。

用静态连接方式解决依赖问题，一个两个程序还行，做到系统一级以目前的视角看比较搞笑。
开源世界比较常用的闭源软件，现在提供的几乎都是动态连接版本，skype、dropbox、opera……

飞龙在天

让每个Linux的软件包都自带关联库，应该是不可能的。所以出此下策而静态编译极少数的几个软件包——xorg、kde、xfce等几个桌面必备的软件。永中office就不错，只要有桌面环境就能完美地来运行。我就想来做成这样的软件安装包。

静态这一名词应该是不合适，自依赖比较恰当点。

飞龙在天

有这样的想法也是因为LFS的特点而发的——因为LFS没有解决依赖关系的包管理器。其他的发行版要么本身就是一个庞大的自给自足软件包。要么就是有一个能根据依赖关系而组合“自给软件包”的管理器。这些所谓的发行版存在的一个主要理由就是解决软件的依赖关系。
如果我们这样来做：内核+GUI等基本功能作为最基础的库，其余的软件将存在发行版需求库的问题，只存在开发用的库，那该是怎样的一个局面？——我仅安装一个基本系统，需要什么软件我就从网站上下载软件包，直接就能用。多好
对于开发者，他们可以用公用库的形式来解决开发效率的问题。但我们最终的用户没必要跟开发者一样，到处去找依赖库去。
windows好像就是这样做的——没有那么多软件说你必须先安装那个那个软件，才能用我。都是傻瓜式地“下一步”点到底完事。

从这点来说软件做成自依赖的安装包说法比较合适。