net-tools的问题解决了

kj501

今天仔细察看了昨天安装net-tools-1.60的错误提示，如下：
cc -D_GNU_SOURCE -O2 -Wall -g  -I. -idirafter ./include/ -Ilib   -c -o ifconfig.o ifconfig.c
cc  -Llib -o ifconfig ifconfig.o -lnet-tools
cc -D_GNU_SOURCE -O2 -Wall -g  -I. -idirafter ./include/ -Ilib   -c -o hostname.o hostname.c
hostname.c:47:24: netdnet/dn.h: No such file or directory
hostname.c: In function `setnname':
hostname.c:72: warning: implicit declaration of function `setnodename'
hostname.c:81: warning: deprecated use of label at end of compound statement
hostname.c:82: warning: implicit declaration of function `exit'
hostname.c: In function `sethname':
hostname.c:101: warning: deprecated use of label at end of compound statement
hostname.c: In function `setdname':
hostname.c:120: warning: deprecated use of label at end of compound statement
hostname.c: In function `showhname':
hostname.c:177: warning: deprecated use of label at end of compound statement
hostname.c: In function `main':
hostname.c:389: warning: implicit declaration of function `getnodename'
make: *** [hostname.o] Error 1
发现问题出在hostname.c找不到 netdnet/dn.h文件，看来又是头文件缺少的问题。到$LFS/usr/include下察看，没有发现有netdnet目录，再到/usr/include下察看，也没有netdnet目录。这就奇怪了。在hostname.c中可是要引用这个目录下的dn.h头文件的，如果在/usr/include下有，还可以复制过去。现在没有，到哪里去找？
是不是缺少某个软件包没有安装？于是进入mandrake控制中心，以“net”为关键字搜索，把找到的软件包全装上。再察看/usr/include目录，还是没有netdnet。迫于无奈，以find / -name dn.h进行搜索，在$LFS/usr下找到3个dn.h文件，如下：
/mnt/lfs/usr/include/linux/dn.h
/mnt/lfs/usr/src/linux-2.4.19/include/linux/dn.h
/mnt/lfs/usr/src/linux-2.4.19/include/net/dn.h
在$LFS/usr/include下建立netdnet目录，然后复制$LFS/usr/include/linux/dn.h到这个目录下，将原来的net-tools-1.60目录删去，重新解压生成net-tools-1.60，进入后重新编译，编译成功。

tram

强啊，辛苦你了！你的经验对后来的人有很重大的意义，对装过的人也是非常有用的，谢谢！

doooom

我的这个文件就是在/usr/include/linux目录下面的。如果以后还是总有这样的麻烦事的话，我想最好还是把第5章涉及到的工具再检查一下，或者干脆重新编译一下。具体关注几个叫utils的包。

sleeve

我的任何一个系统里的/usr/include/linux 和/usr/include/asm都是个符号连接..连接到/usr/src/linux/include/linux 和asm 因为我经常使用不同的内核,这样系统可以保持和内核版本同步相同..我想在装lfs之前应该先把内核的源代码解开并连接好..就不会出现这类的问题.....

doooom

我知道了，就向/lib/modules/2.4.20/kernel/build 一样。

在lfs的里面这个不是连接而是一个目录。因为suppose这个源码目录以后是可以山掉的。

tram

在LFS里是不能用符号链接的，因为如果升级了内核，那么glibc所用到的头文件就不在了。

sleeve

那如果把内核的include/linux复制到那个/usr/include呢..
glibc的什么头文件..为什么放到这个目录呢？glibc不是在其他unix都可以用的么？

tram

下面是LFS书里对这个问题的解释：
为什么我们不是创建这些目录的链接而是拷贝它们

过去人们通常是创建从 /usr/include/{linux,asm} 目录到 /usr/src/linux/include/{linux,asm} 的符号链接。这是一种不好的行为，在下面 Linus Torvalds (Linux之父)写到 Linux Kernel Mailing List 信的节选中说:

I would suggest that people who compile new kernels should:

- not have a single symbolic link in sight (except the one that the
   kernel build itself sets up, namely the "linux/include/asm" symlink
   that is only used for the internal kernel compile itself)

And yes, this is what I do. My /usr/src/linux still has the old 2.2.13
header files, even though I haven't run a 2.2.13 kernel in a _loong_
time. But those headers were what glibc was compiled against, so those
headers are what matches the library object files.

And this is actually what has been the suggested environment for at
least the last five years. I don't know why the symlink business keeps
on living on, like a bad zombie. Pretty much every distribution still
has that broken symlink, and people still remember that the linux
sources should go into "/usr/src/linux" even though that hasn't been
true in a _loong_ time.

Linus 所说的精华部份是头文件应该是 glibc 编译时链接到的. 我们这里的头文件是你后面编译其它包时要用到的，因为它们是与对象(object-code)库文件相匹配的。通过拷贝头文件，我们保证它们在你以后升级内核后能继续使用它们。

注意，附带着说一句，内核代码在 /usr/src/linux 目录里是能正确使用的，只要你没有创建 /usr/include/{linux,asm} 的符号链接。

sleeve

那如果升级内核的话..（linux,asm）的类型出现定义不同的话..不会出现什么问题吧？

tram

我想Linus Torvalds这么做肯定有他的道理的，呵呵，还有，LFS中的人也没有碰到你说的这个问题啊，因为glibc是用头文件来编译的，那可能就不能改了吧，不过我也没有更多的经验，不知道会出什么问题，就按他说的做了，呵呵。