请教几个小问题

lofeng410

Post by 晨想;1897558
第二个，以前有个 paco 可以跟踪，或者 make install 的时候加上 DESTDIR=xxx 这个参数，就可以装到xxx目录去，而不是猿类定的 prefix 中。

目前我对于哪些工具装在哪里比较合适还没有系统的概念，所以还是选择安装到prefix中。

lofeng410

ld的库搜索路径有明确的要求，手册中也给出了保证库搜索路径正确的措施。
但是，动态连接器也是需要搜索库的，是否是直接搜索glibc的安装位置即/lib、/usr/lib等位置而不需要控制？但是这样怎么控制是搜索宿主中的glibc还是搜索工具链中安装的glibc呢？

d00m3d

Post by lofeng410;1897566
目前我对于哪些工具装在哪里比较合适还没有系统的概念，所以还是选择安装到prefix中。

LFS 跟发行版不同，没有强劲的包管理系统去管理包及自动解决包的依赖，现有的包管理系统功能都比较有限

paco 我一直在用，它也有 GUI （可选择不装）的，但依赖甚多。对 LFSer 来说，paco 算是可用的，但别期望它能跟 apt、yum、portage 较劲了

lofeng410

Post by ti8er;1897530
1、看不懂你的意思。。。。
是不是比如
ls -l
你想看看ls这个指令的完整路径在哪里？
那么
whereis ls
就可以找到。

在第一遍make install完binutils后，whereis －b ld 的输出是：
/usr/bin/ld
为什么结果中没有包含/tools/bin/ld？

虽然通过ld --verbose｜grep SEARCH看到ld的库搜索路径已经由：
/usr/i486-pc-linux-gnu/lib
/usr/local/lib
/lib
/usr/lib
改变为：
/tools/i686-pc-linux-gnu/lib
/tools/lib
/usr/local/lib
/lib
/usr/lib

可以看出ld已经编译好了，而且在/tools/bin目录下已经有了ld，而且PATH中/tools/bin排在最前面。那为什么whereis ld 的结果是那样的呢？

lofeng410

在第一遍binutils时，最后为第一次工具链的调整准备ld，
make -C ld LIB_PATH=/tools/lib成功执行后，
ld/ld-new --verbose |grep SEARCH结果为：
/tools/i686-pc-linux-gnu/lib
/tools/lib
-----------------------------------------------------------
在手册中有如下的解释：
-C ld LIB_PATH=/tools/lib

This option rebuilds everything in the ld subdirectory. Specifying the LIB_PATH Makefile variable on the command line allows us to override the default value and point it to the temporary tools location. The value of this variable specifies the linker's default library search path.
从上面的解释看，ld-new的库搜索路径应该是只有/tools/lib的，现在怎么在他前面多了个/tools/i686-pc-linux-gnu/lib？

lofeng410

把ld-new拷贝到/tools/bin中去，执行whereis ld-new，同第十四帖，也不能得出想要的结果。
起结果为ld-new

lofeng410

用which -a ld得出的结果是：
/tools/bin/ld
/usr/bin/ld
因为which是在PATH里面搜索，但是whereis没有限制范围，怎么还不能得出结果？
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
既然shell中执行的指令没有给出路径时是在PATH里面搜索的，那用which是否就已经足够满足我第一帖中的第一点要求？

lofeng410

-print-prog-name=<程序>
显示编译器组件 <程序> 的完整路径
这是我gcc --help是得到的，但是-print-prog-name=ld输出的结果只是ld，根本不是完整路径，这是为何呢？是我没有用对这个指令还是？

ti8er

Post by lofeng410;1897563
手册中说的我基本上明白，现在正在具体的看看每一步都是怎么变化的，呵呵~~

对于那个动态链接器，还有个就是它连接的库的问题。/etc/ld.so.conf这个文件只是在5.6中Glibc的编译过程中为了解决一个无关紧要的warning而生成的，这个文件决定着编译时使用的动态链接库，为什么在这里没有重视？

在编译的时候，Warning是一闪而过的，所以你是根本看不到的。除非你设置把Warning也当成错误，那么就会在那里停住。这个设置可以用gcc的相关参数来完成。

ti8er

Post by lofeng410;1897683
在第一遍binutils时，最后为第一次工具链的调整准备ld，
make -C ld LIB_PATH=/tools/lib成功执行后，
ld/ld-new --verbose |grep SEARCH结果为：
/tools/i686-pc-linux-gnu/lib
/tools/lib
-----------------------------------------------------------
在手册中有如下的解释：
-C ld LIB_PATH=/tools/lib

This option rebuilds everything in the ld subdirectory. Specifying the LIB_PATH Makefile variable on the command line allows us to override the default value and point it to the temporary tools location. The value of this variable specifies the linker's default library search path.
从上面的解释看，ld-new的库搜索路径应该是只有/tools/lib的，现在怎么在他前面多了个/tools/i686-pc-linux-gnu/lib？

这个i686的目录，是GCC编译器自动加上去的。这是你系统的“构架”，GCC编译器必须要知道你系统的构架，才能正确地编译程序。

比如：686和386的构架就是不一样的。
原因是处理器的指令不同，686的指令要多过386。还记得我之前说过，所有的程序都是机器语言执行的吗？GCC要把程序编译为机器程序，那么它必须首先要知道，你的机器到底有哪些机器语言的指令。

当然，386构架是通用的。但是，由于它指令少，那么将无法达到最快的速度。

由于ld和GCC是绑在一块的，所以也会加上这个目录。