第六章Glibc-2.3.4又出问题了，请看看。

barebrain

我在执行完   （应该是第六章的6。11这节）
tar xvf $LFS/glibc-2.3.4.tar.bz2
cd glibc-2.3.4
tar -xjvf $LFS/glibc-linuxthreads-2.3.4.tar.bz2
patch -Np1 -i $LFS/glibc-2.3.4-rtld_search_dirs-1.patch
patch -Np1 -i $LFS/glibc-2.3.4-fix_test-1.patch
patch -Np1 -i $LFS/glibc-2.3.4-tls_assert-1.patch
mkdir -v ../glibc-build
cd ../glibc-build
../glibc-2.3.4/configure --prefix=/usr \
    --disable-profile --enable-add-ons \
    --enable-kernel=2.6.0 --libexecdir=/usr/lib/glibc
之后出现了
checking for suffix of object files...  configure: error: cannot compute suffix of object files: cannot compile
see 'config.log' for more details.
root:/sources/glibc-build#
谁能帮忙解决下呀，越详细越好，谢谢。

barebrain

是不是没救了，要重新开始呀？

d00m3d

config.log 的内容是什麽？

bzf2002

我也遇到了相同的问题，现在安装不下去了，你现在解决了吗？是怎么解决的？

youbest

有可能是当前的gcc有问题

energumen

先说一下问题的起因：
这个问题的原因是gcc无法找到的问题，也就是说，你在chroot以后，执行gcc -v显示的是没有那个文件，而你在$LFS下面执行gcc -v ，结果是正确的，如下所示：
lfs:/mnt/hdd/sources/patch-2.5.4$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.0-patch/configure --prefix=/tools --libexecdir=/tools/lib --with-local-prefix=/tools --enable-clocale=gnu --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-languages=c,c++ --disable-libstdcxx-pch
Thread model: posix
gcc version 4.1.0

这说明问题：gcc没有正确的链接到glibc，针对这个状况，有如下两种解决方案：


第一种：快速但是痛苦的方法
将gcc给编译成静态链接的 也就是我在http://www.linuxsir.cn/bbs/showt ... 1里面所说的：
我推荐的方法：
直接在lfs用户编译的时候，再把gcc给静态编译一次，也就是
../gcc-2.4/configure **** 之后，在gcc-build目录下面生成了Makefile
将Makefile里面的CFLAGS_FOR_BUILD补充一个--static

重新编译以后，gcc就可以正常运行了

错误回放一遍：
在lfs用户下面，gcc -v，
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.1-static/configure --prefix=/tools/gcc-4.1.1 --libexecdir=/tools/lib --with-local-prefix=/tools --enable-clocale=gnu --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-languages=c,c++ --disable-libstdcxx-pch
Thread model: posix
gcc version 4.1.1

正确
chroot以后，gcc -v
结果得到的却是：no such file or directory

使用strace 跟踪以后发现execv("/tools/bin/gcc","-v"***)的时候出错，报没有找到这个文件。但是该文件确实存在

所以定位不了问题，就多半是动态链接库的问题，干脆改成静态链接的好了，反正我只是要新版本的glibc，gcc的大小我不关心

这样做带来的后果是：无法生成任何调用gcc动态链接库的东西，也就是必须严格禁止-g参数的设置，这样会给后续的编译带来很多问题，完全不推荐

晨想

LFS 根本不需要这样做。
静态编译 是最不好的方式，不是非常特殊的要求，不要用静态编译。

energumen

既然知道是gcc出了问题，那么就可以选择重新编译

我只说我重新编译时候的情况：
1、注意什么时候该打补丁
对应不同版本的程序，cross building的补丁都可以从http://lfs.phayoune.org/patches/downloads/下载
注意：binutils和gcc的pass 1都是不用打补丁的，而pass 2是一定要打补丁的。至于phrase 2也是一定不要打补丁的，一定要注意这个

2、为了回退方便，重新编译方便，请保留所有的源目录
我当时明白我自己是不可能一遍成功的，所以编译的目录和源目录都这样命名：
gcc-4.1.0-src gcc-4.1.0-src-patched
gcc-4.1.0-build-pass1 gcc-4.1.0-build-pass2 gcc-4.1.0-build-phrase2

3、需要注意的是gcc的specs文件的生成，用LFS上面的方法无法生成，可以用下面的指令：gcc -dumpspecs | sed "s,/lib/ld-linux.so.2,/tools/lib/ld-linux.so.2,g" > `gcc -print-search-dirs | head -n 1 | awk '{ print $2 }'`specs

4、注意几次ld 的lib目录的切换，这个是LFS成功的关键
在5.7第一次调整工具链之前，ld的缺省库搜索路径就是你原来系统的/lib
在5.7第一次调整工具链之后，ld的缺省库搜索路径变成/tools/lib，一直到6.12的再次调整工具链
在6.12再次调整工具链之后，ld的缺省库搜索路径变成你chroot以后的/lib。
这几次变幻，请均使用：
echo 'main(){}' > dummy.c
cc dummy.c
readelf -l a.out | grep ': /lib'（用于检测是否工作路径是/lib）
readelf -l a.out | grep ': /tools/lib'（用于检测是否工作路径是/tools/lib）
来进行检测
如果不正确，请回退跟踪

barebrain

我好象是重新开始又做了一变，虽然lfs已经完成，但是总觉得什么地方出了问题，开始做的时候真实太痛苦了，不知道重新做了多少次，结果发现lfs比我想要的大了好多。坚持就是胜利，加油把。

youbest

strip后300多M是正常的.