[lfs-support] How Glibc builds itself at LFS 7.1: 5.7. Glibc-2.14.1

Yasser Zamani yasser.zamani at live.com
Wed Jun 6 04:29:58 PDT 2012

Actually I already have been finished LFS 7.1 without any problem but once again I decided to repeat the process but this time with latest versions of packages and Linux kernel. I successfully done following sections:

5.4. Binutils-2.22 - Pass 1
5.5. GCC-4.7.0 - Pass 1

I used latest MPFR, GMP and MPC with no problem
I saw "libiberty and zlib target"'s patch file and applied it manually
I used GCC-4.7.0 instead
5.6. Linux-3.3.7 API Headers

I used version 3.3.7 instead
But in sectin "5.7. Glibc-2.14.1"

I used Glibc-2.15 instead
I saw cpuid and other patch files and applied them manually
Then when I tried to configure package with following command:
../glibc-2.15/configure --prefix=/tools --host=i686-lfs-linux-gnu --build=i686-pc-linux-gnu --disable-profile --enable-add-ons --enable-kernel=3.3.7 --with-headers=/tools/include libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes
It told me on screen:
checking whether to use .ctors/.dtors header and trailer... configure: error: missing __attribute__ ((constructor)) support??

Then I looked for relevant info at config.log and I found:
configure:6180: checking whether to use .ctors/.dtors header and trailer
configure:6200: i686-lfs-linux-gnu-gcc -o conftest -g -O2 conftest.c >&5
/mnt/sda1/tools/bin/../lib/gcc/i686-lfs-linux-gnu/4.7.0/../../../../i686-lfs-linux-gnu/bin/ld: cannot find crt1.o: No such file or directory
/mnt/sda1/tools/bin/../lib/gcc/i686-lfs-linux-gnu/4.7.0/../../../../i686-lfs-linux-gnu/bin/ld: cannot find crti.o: No such file or directory
/mnt/sda1/tools/bin/../lib/gcc/i686-lfs-linux-gnu/4.7.0/../../../../i686-lfs-linux-gnu/bin/ld: cannot find -lc
/mnt/sda1/tools/bin/../lib/gcc/i686-lfs-linux-gnu/4.7.0/../../../../i686-lfs-linux-gnu/bin/ld: cannot find crtn.o: No such file or directory
collect2: error: ld returned 1 exit status
configure:6200: $? = 1
OK, the thing which I could not understand is...
I know at this time Glibc will be compiled and linked with the new toolchain inside of $LFS/tools rather than host's one. So the linker looks for crt*.o inside of my new toolchain lib i.e. $LFS/lib and it does not find any thing then throws this error; but the thing that have been confused me is "How the normal LFS 7.1 (I mean current book with it's cited package's versions) passes this stage with no need to host's Glibc i.e. crt*.o?!"

"ln -sv /lib/crt*.o ..." solved this problem but caused much more another problems.

"uname -r"'s result is:
Thanks in advance!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-support/attachments/20120606/d0e2a810/attachment.html>

More information about the lfs-support mailing list