请教几个小问题

在LFS的过程中，为了验证自己的一些想法，请教几个弱弱的问题：
1.能否列出使用指令的完整路径？
2.在make install完成后，如何查看make install安装了哪些程序？譬如说make 、make install完成后，如何查看在哪些位置安装了哪些程序？

作者: lofeng410 发布时间: 2008-10-22

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

2、在make install 的时候使用：

make install | tee temp

在temp中就会有install时候的详细信息，那么你就可以了解到底安装了哪些目录和文件。
如果你想直观点，那么把temp改名，比如安装gcc的时候就改为

make install | tee gcc4-1-2.install

这样就可以自己看了。当然看Makefile也能看出装了哪些东西，如果你对Makefile很了解的话。
LFS手册中，也提到了安装哪些东西，都是比较准确的。

不过我也不清楚是不是还有更好的方法看到安装了哪些东西。

提示：有的软件支持卸载，命令为

make uninstall

但是也不是所有的都可以这么做的。

作者: ti8er 发布时间: 2008-10-22

引用:

作者: ti8er

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

2、在make install 的时候使用：

make install | tee temp

在temp中就会有install时候的详细信息，那么你就可以了解到底安装了哪些目录和文件。
如果你想直观点，那么把temp改名，比如安装gcc的时候就改为

make install | tee gcc4-1-2.install

这样就可以自己看了。当然看Makefile也能看出装了哪些东西，如果你对Makefile很了解的话。
LFS手册中，也提到了安装哪些东西，都是比较准确的。

不过我也不清楚是不是还有更好的方法看到安装了哪些东西。

提示：有的软件支持卸载，命令为

make uninstall

但是也不是所有的都可以这么做的。

不好意思，第一个问题表述的不清楚，语文功底太差，呵呵~~
whereis这个指令能满足我的需求，我的本意是想在执行ls -l等指令的时候，在显示执行结果的同时显示使用的ls指令的绝对地址。

第二个问题是我在编译binutils时，在binutils-build目录有这样两个文件夹：ld和binutils，里面有make后生成的诸如ld-new、ar等工具，所以就想知道咱make install的过程中具体安装了哪些程序。特别的是ld-new安装到/tools/bin目录下为ld，我也想看看这个重命名的该过程。至于具体的安装位置，虽然configure是已经指定了--prefix=/tools，但是这些工具最后安装的位置可能是bin也可能是sbin目录，库的安装就更如此了，所以就很香知道具体的安装位置。

至于make uninsatll，在LFS过程中用的那些工具，好像都没有提供make uninstall

作者: lofeng410 发布时间: 2008-10-22

要显示绝对地址可能要脚本才行了。其实你
echo $PATH

就可以知道应用程序访问的先后路径。
再
whereis gcc
就可以知道gcc是用了哪里的了。这点在你系统有2个gcc的时候比较有用。

安装哪些文件和哪些库，用我说到的指令，在生成的文件里全部都有列出来的。只是信息很多，可能比较难看而已。
如果你真想明白，那么你需要去学习一下Makefile的知识。我目前正在学习。

作者: ti8er 发布时间: 2008-10-22

根据手册上说的，在构建工具链过程中，最重要的是要确保两点：
1.ld的库文件搜索路径。在binutils第一遍时先使用的是宿主中的库文件，make后安装到/tools目录，然后通过LIB-PATH来指定库的搜索路径，编译出在/tools目录先安装好glibc后使用的ld，在binutils第二遍时类似的过程。
2.gcc使用的是哪个dynamic linker。在手册里主要是通过在`dirname $(gcc -print-libgcc-file-name)`放置修改过的specs文件来实现的。
现在我想具体的看下每做完一步后相应的变化是什么。

还有gcc自身带有一个叫做libgcc的库，这个库又有什么作用的呢？

作者: lofeng410 发布时间: 2008-10-22

引用:

作者: ti8er

安装哪些文件和哪些库，用我说到的指令，在生成的文件里全部都有列出来的。只是信息很多，可能比较难看而已。
如果你真想明白，那么你需要去学习一下Makefile的知识。我目前正在学习。

在弄完LFS中的大部分问题再朝那个方向努力，要学的东西太多了，有点忙不过来了。呵呵~~

作者: lofeng410 发布时间: 2008-10-22

工具链调整是很关键的。所以要确保使用了正确的ld和gcc

所以，在第5章，一定要确保PATH中
/tools/bin这个目录必须排在第一个，以强制系统首先使用正确的ld和gcc。

然后，如何确保ld指向了正确的库？LFS手册已经教你怎么做了，看第5.7章，他用gcc编译了一个新的测试文件，然后用realelf来查看使用的库是不是正确的库。
如果不是的话，那就要重新调整了。

作者: ti8er 发布时间: 2008-10-22

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

作者: 晨想发布时间: 2008-10-22

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

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

引用:

The install stage of Glibc will issue a harmless warning at the end about the absence of /tools/etc/ld.so.conf. Prevent this warning with:

mkdir -v /tools/etc
touch /tools/etc/ld.so.conf

作者: lofeng410 发布时间: 2008-10-22

引用:

作者: ti8er

工具链调整是很关键的。所以要确保使用了正确的ld和gcc

所以，在第5章，一定要确保PATH中
/tools/bin这个目录必须排在第一个，以强制系统首先使用正确的ld和gcc。

在做的过程中我一直按照你前面说的，时刻关注PATH的值，这上面应该不会出错。呵呵~~

作者: lofeng410 发布时间: 2008-10-22

引用:

作者: 晨想

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

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

作者: lofeng410 发布时间: 2008-10-22

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

作者: lofeng410 发布时间: 2008-10-22

引用:

作者: lofeng410

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

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

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

上传的图像

gpaco.png (36.3 KB, 22 次查看)

作者: d00m3d 发布时间: 2008-10-22

引用:

作者: ti8er

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 发布时间: 2008-10-23

在第一遍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 发布时间: 2008-10-23

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

作者: lofeng410 发布时间: 2008-10-23

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

作者: lofeng410 发布时间: 2008-10-23

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

作者: lofeng410 发布时间: 2008-10-23

引用:

作者: lofeng410

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

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

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

作者: ti8er 发布时间: 2008-10-23

引用:

作者: 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？

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

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

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

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

作者: ti8er 发布时间: 2008-10-23

引用:

作者: lofeng410

在第一遍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 的结果是那样的呢？

第一遍编译ld的时候，你的/tools目录下是没有ld的，ld是“刚刚生成”的。但是，编译ld，本身就需要另一个“ld"，这个ld就在/usr/bin目录下。

whereis 指令，会找到上一次使用的指令的位置。对于新增加而“没有执行”过的，它会有一个缓冲。所以你刚刚在/tools/bin中增加的ld，用whereis是找不到的。

你可以再输入一次ld命令。Bash将会按照PATH路径找到/tools/bin下的ld。这时whereis的缓冲就有了。
如果你这时再运行whereis ld，应该将显示

/tools/bin/ld;/usr/bin/ld

同理，你“刚刚”拷贝过去的ld-new，没有运行它的话，你直接whereis ld-new，也是找不到的。

作者: ti8er 发布时间: 2008-10-23

引用:

作者: lofeng410

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

是的，which就满足要求，它直接搜索PATH，不像whereis有缓冲。只是我用whereis多一些，因为它可以找到lib，还能找到很多东西，只要这个东西在SHELL运行的过程中使用过就可以找到。这样就可以分析。而which功能就简单点。

作者: ti8er 发布时间: 2008-10-23

我还找到了一个更简单的办法，可以发现你用make install的时候到底装了哪些东西：

那就是超级强大的find命令！
命令如下：

find /tools -mmin -2

解释：在/tools目录下查找之前2分钟内改变过的文件。

把2改成你想要的任何时间就可以了。
这个灵感得益于LFS手册中的“包管理”那一节。其中的一种包管理方法就是用时间戳。

你可以在上面的命令加管道，导入另一个文件作为查看。比如用>、或者用tee都可以。

我的包管理是用了第一种方式：全部记住！哈哈。

作者: ti8er 发布时间: 2008-10-23

引用:

作者: lofeng410

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

我看了man手册，用法是：

which `gcc -print-prog-name=ld`

我也搞不清楚和直接which ld有什么区别呵呵。

作者: ti8er 发布时间: 2008-10-23

引用:

作者: ti8er

引用:

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

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

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

我的意思不是说如何解决这个warning。根据手册中说的，

引用:

The install stage of Glibc will issue a harmless warning at the end about the absence of /tools/etc/ld.so.conf. Prevent this warning with:

mkdir -v /tools/etc
touch /tools/etc/ld.so.conf

ld.so.conf这个文件可要可不要，但是这个文件不是决定着动态链接器寻找库的路径么？怎么在这里却是可有可无的？

在手册里强调了一定要使用正确的动态连接器，但是动态链接器搜索库的路径同样重要的，但是这点好像一直都没有强调，所以有次疑惑。GCC在安装的过程中会生成一个叫做libgcc的库，这个库有什么用处的呢？

作者: lofeng410 发布时间: 2008-10-23

引用:

作者: ti8er

我还找到了一个更简单的办法，可以发现你用make install的时候到底装了哪些东西：

那就是超级强大的find命令！
命令如下：

find /tools -mmin -2

解释：在/tools目录下查找之前2分钟内改变过的文件。

把2改成你想要的任何时间就可以了。
这个灵感得益于LFS手册中的“包管理”那一节。其中的一种包管理方法就是用时间戳。

你可以在上面的命令加管道，导入另一个文件作为查看。比如用>、或者用tee都可以。

我的包管理是用了第一种方式：全部记住！哈哈。

这个find确实很强大~~
你的包管理方式也很强大，我也是也这样的话最后肯定会乱套的。呵呵~~

作者: lofeng410 发布时间: 2008-10-23

引用:

作者: lofeng410

我的意思不是说如何解决这个warning。根据手册中说的，

ld.so.conf这个文件可要可不要，但是这个文件不是决定着动态链接器寻找库的路径么？怎么在这里却是可有可无的？

在手册里强调了一定要使用正确的动态连接器，但是动态链接器搜索库的路径同样重要的，但是这点好像一直都没有强调，所以有次疑惑。GCC在安装的过程中会生成一个叫做libgcc的库，这个库有什么用处的呢？

看来你还没搞清楚，或者是自己把自己搞乱了。看看我之前写的一篇文章：注意里面提到的工具链编译公式：

http://www.linuxsir.org/bbs/thread335436.html

5.6章编译的Glibc，依赖的是系统的ld.so.conf，也就是/etc/ld.so.conf，5.6章增加的是/tools/etc/ld.so.conf，
看清楚了。别搞错了对象：到底是哪个决定动态连接库。

GCC生成的libgcc库，是GCC本身需要的。没有它，GCC本身就不能运行起来。

libgcc Contains run-time support for gcc

作者: ti8er 发布时间: 2008-10-23

引用:

作者: ti8er

看来你还没搞清楚，或者是自己把自己搞乱了。看看我之前写的一篇文章：注意里面提到的工具链编译公式：

http://www.linuxsir.org/bbs/thread335436.html

5.6章编译的Glibc，依赖的是系统的ld.so.conf，也就是/etc/ld.so.conf，5.6章增加的是/tools/etc/ld.so.conf，
看清楚了。别搞错了对象：到底是哪个决定动态连接库。

GCC生成的libgcc库，是GCC本身需要的。没有它，GCC本身就不能运行起来。

libgcc Contains run-time support for gcc

仔细看了那篇文章，基本上理解了。但是对于你在文章中提到的这个概念感到迷惑的很：

引用:

有了虚根环境，还会再一次编译库文件。这是因为之前编译的LIB-B是经过重定位装在别的地方的（可见重定位的麻烦），
你要编译一个新的没有重定位的库文件，装在默认的地方，以便将来你的程序都可以利用它。这时生成了LIB-C。
LIB-B＋GCC-B2＋LD-B2＝＝＞LIB-C。
然后，编译GCC和LD，将它们之前的重定位去掉。
LIB-C＋GCC-B2＋LD-B2＝＝＞LD-C
LIB-C＋GCC-B2＋LD-C＝＝＞GCC-C

这里的重定位一直没有搞清楚是什么含义。

另外我查了下cat /etc/ld.so.conf的内容，在LFS-LIVECD中为：
/usr/local/lib
/opt/lib
觉得其实在LFS的过程中ld.so.conf没有起到什么作用。在LFS过程中动态连接器需要搜索的库都在/lib、/usr/lib目录下，根本用不上其他目录下的动态库。

作者: lofeng410 发布时间: 2008-10-23

在坛子里看到的关于动态连接器搜索库路径的东东：
在Linux下，大部分系统的library库被安装在/usr/lib目录下。只有一些基本的共享库被安装在/lib目录下。例如：libc.so,libcurses.so,libm.so,libtermcap.so(各个版本对应的文件会有些不同)，在其他部分被mount上之前，那些文件是启动Linux系统所必须的。连接器默认的搜索路径是/lib,/usr/lib,/usr/local/lib。

环境变量LD_LIBRARY_PATH列出了查找共享库时除了默认路径之外的其他路径。
/etc/ld.so.conf文件则指出了程序ldconfig要搜索的目录。该程序将这些目录中所有的共享库都存储到/etc/ld.so.cache中。假如共享库已经被从默认的目录中移走，Linux ELF动态连接库将在/etc/ld.so.cache文件中找该共享库。

程序ldconfig将把/etc/ld.so.conf文件中列出的搜索目录中的所有的共享库存储到/etcld.so.cache中。假如共享库已经被从默认的目录中移走，Linux ELF动态连接库将在/etc/ld.so.cache文件中找该共享库。

对于普通用户无法修改/etc/ld.so.conf,又想用其他位置的库，就可以用LD_LIBRARY_PATH

作者: lofeng410 发布时间: 2008-10-23

恩，不错。这样就更加清楚了。

作者: ti8er 发布时间: 2008-10-23

发觉LIVE CD建立的环境不是很稳定可靠
现在6个终端被我给弄死了5个,Ctrl+C什么的都不行
赶紧用第6个终端reboot，结果敲入命令后也死在那了

作者: lofeng410 发布时间: 2008-10-24

那估计是你误操作删除了系统文件了。重启电脑吧。

如果是硬盘系统的话，早挂了，要重装了。

作者: ti8er 发布时间: 2008-10-24

5.7第一次调整工具链时修正specs文件，使它指向新的动态链接器/tools/lib/ld-linux.so.2。这个修正使得在接下来的编译生成的程序都将使用新的动态链接器/tools/lib/ld-linux.so.2，而第一次生成的GCC运行时还是需要host中的/lib/ld-linux.so.2。
因为ldd /tools/bin/gcc 可知其使用的动态链接器是host中的/lib/ld-linux.so.2
因此调整了库的搜索路径后，还是需要重新编译GCC、Binutils，使其纯正。
个人觉得这时第二次编译GCC、Binutils的主要缘故，不知可对，还请斧正。

作者: lofeng410 发布时间: 2008-10-24

可执行文件中总是把动态链接器的绝对地址编码进去，这个最可恨

而这个硬编码进去的动态链接器又决定了它搜寻库的路径和顺序

作者: lofeng410 发布时间: 2008-10-24

是的，非常正确！

作者: ti8er 发布时间: 2008-10-24

ldd /usr/bin/gcc
输出为：
linux-gate.so.1=>(0x......)
libc.so.6=>/lib/libc.so.6(0x......)
/lib/ld-linux.so.2(0x......)
------------------------------------------------------------------------------------------------------------------------------------
这个输出有点看不懂，最后一行还好明白，直接显示绝对地址和偏移地址（括号里面的应该是偏移地址的吧）。
第一行没有显示什么地址，是否就是直接去相应的lib中（也就是ld.so.cache中去寻找）搜索linux-gate.so.1？
第二行中包含的地址又是什么含义呢？不会是直接包含到可执行文件中去的吧？

另外，有路径的意味着只要在那个位置存在那个文件，就一定能够找到。而没有路径的，有事按照什么样的方式去搜索呢？

作者: lofeng410 发布时间: 2008-10-24

引用:

作者: lofeng410

ldd /usr/bin/gcc
输出为：
linux-gate.so.1=>(0x......)
libc.so.6=>/lib/libc.so.6(0x......)
/lib/ld-linux.so.2(0x......)
------------------------------------------------------------------------------------------------------------------------------------
这个输出有点看不懂，最后一行还好明白，直接显示绝对地址和偏移地址（括号里面的应该是偏移地址的吧）。
第一行没有显示什么地址，是否就是直接去相应的lib中（也就是ld.so.cache中去寻找）搜索linux-gate.so.1？
第二行中包含的地址又是什么含义呢？不会是直接包含到可执行文件中去的吧？

另外，有路径的意味着只要在那个位置存在那个文件，就一定能够找到。而没有路径的，有事按照什么样的方式去搜索呢？

ldd显示的是程序的“共享库”内容。

Linux下，每个程序要运行，都需要三个条件：
1、二进制文件bin
2、库文件lib
3、配置文件etc

其中，库文件分两种，一种是“静态”库，这种库只有二进制文件自己使用。这种库的后缀为.a

另一种是共享库，这种库其他的二进制文件都可以使用。这种库的后缀为.so。

像上面的命令，打印出来的就是gcc程序用到的共享库。
第一个是Linux门，它是Linux内核与用户程序连接的库。
第二个是Glibc提供的一个共享库。
第三个是ld提供的共享库。

库名字的后面就是这个库加载的地址。可以叫偏移地址，其实就是内存的高阶地址。

作者: ti8er 发布时间: 2008-10-24

这些库文件的知识，在BLFS手册中会提到。

作者: ti8er 发布时间: 2008-10-24

引用:

作者: ti8er

ldd显示的是程序的“共享库”内容。

Linux下，每个程序要运行，都需要三个条件：
1、二进制文件bin
2、库文件lib
3、配置文件etc

其中，库文件分两种，一种是“静态”库，这种库只有二进制文件自己使用。这种库的后缀为.a

另一种是共享库，这种库其他的二进制文件都可以使用。这种库的后缀为.so。

像上面的命令，打印出来的就是gcc程序用到的共享库。
第一个是Linux门，它是Linux内核与用户程序连接的库。
第二个是Glibc提供的一个共享库。
第三个是ld提供的共享库。

库名字的后面就是这个库加载的地址。可以叫偏移地址，其实就是内存的高阶地址。

还是没有理解为什么有的有绝对路径、而有的没有？

作者: lofeng410 发布时间: 2008-10-24

引用:

作者: lofeng410

还是没有理解为什么有的有绝对路径、而有的没有？

我也不知道……
我觉得是风格问题。比如没有绝对路径的，表示系统级别；
有绝对路径的，表示用户程序级别。

这有点像C语言程序变量在前面加一个或者两个下划线一样。

作者: ti8er 发布时间: 2008-10-24

友情提示：linux-gate 是不存在的。。：）。

作者: 晨想发布时间: 2008-10-25

引用:

作者: 晨想

友情提示：linux-gate 是不存在的。。：）。

不存在是为何意？小生愚钝，还请版主帮忙解释一下

作者: lofeng410 发布时间: 2008-10-25

引用:

作者: lofeng410

不存在是为何意？小生愚钝，还请版主帮忙解释一下

其实是存在于内核里。不是一个独立出来的库。

作者: ti8er 发布时间: 2008-10-25

引用:

作者: ti8er

其实是存在于内核里。不是一个独立出来的库。

就是说能在内核中找到，于是乎就不需要路径什么的了？

作者: lofeng410 发布时间: 2008-10-25

6.10. Re-adjusting the Toolchain
我写了个包含printf的dummy.c，然后执行下面的命令：
cc dummy.c -v -Wl,--verbose &> dummy.log

vim dummy.log，其中有如下语句：

引用:

attempt to open /tools/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcc.so failed
attempt to open /tools/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcc.a succeeded
attempt to open /tools/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcc_s.so failed
attempt to open /tools/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcc_s.a failed
attempt to open /tools/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../i686-pc-linux-gnu/lib/libgcc_s.so failed
attempt to open /tools/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../i686-pc-linux-gnu/lib/libgcc_s.a failed
attempt to open /tools/bin/../i686-pc-linux-gnu/lib/libgcc_s.so failed
attempt to open /tools/bin/../i686-pc-linux-gnu/lib/libgcc_s.a failed
attempt to open /tools/i686-pc-linux-gnu/lib/libgcc_s.so failed
attempt to open /tools/i686-pc-linux-gnu/lib/libgcc_s.a failed
attempt to open /usr/lib/libgcc_s.so succeeded

而这时ld的搜索路径是：
/tools/i686-pc-linux-gnu/lib
/usr/lib
/lib

但是从上面看好像有搜索这三个路径之外的库，这时何故呢？

上传的附件

dummy.rar (3.0 KB, 1 次查看)

作者: lofeng410 发布时间: 2008-10-25