I am playing with LFS (again), but not following the directions exaclty (playing with uClibc) and currently building Temporary System under /tools. The question that I have is why in binutils run 1 there is --target=$LFS_TGT parameter, while in binutils run 2 there is no such parameter.

The thing is that before running binutils run2 I have the following:
$ echo ${LFS_TGT}
x86_64-lfs-linux-uclibc
sources$ gcc-4.6.1/config.guess
x86_64-unknown-linux-gnu

and binutils is then installed into /tools/x86_64-unknown-linux-gnu

Here is how binutils run2 is configured:

CC="$LFS_TGT-gcc -B/tools/lib/" \
AR=$LFS_TGT-ar RANLIB=$LFS_TGT-ranlib \
../binutils-2.21.1/configure --prefix=/tools \
--disable-nls --with-lib-path=/tools/lib

the environment seems to be fine:

$ echo $LFS_TGT-gcc
x86_64-lfs-linux-uclibc-gcc
$ echo $LFS_TGT-ar
x86_64-lfs-linux-uclibc-ar
$ echo $LFS_TGT-ranlib
x86_64-lfs-linux-uclibc-ranlib



Which step in LFS book ensures that upon building binutils run2, config.guess returns ${LFS_TGT}?

None, straight from the book itself...
"CC="$LFS_TGT-gcc -B/tools/lib/" AR=$LFS_TGT-ar RANLIB=$LFS_TGT-ranlib
Because this is really a native build of Binutils, setting these variables ensures that the build system uses the cross-compiler and associated tools instead of the ones on the host system."

Binutils pass 1 was only ment to build the cross-compiler (not sure why you really need one since LFS only supports 1 arch).

What you are seeing is normal, you are building a NORMAL build of binutils with a cross-compiler.

Thanks, I guess my subsequent GCC pass2 issue is unrelated to Binutils run2:


/mnt/lfs/sources/gcc-build/./gcc/xgcc -B/mnt/lfs/sources/gcc-build/./gcc/ -B/tools/x86_64-unknown-linux-gnu/bin/ -B/tools/x86_64-unknown-linux-gnu/lib/ -isystem /tools/x86_64-unknown-linux-gnu/include -isystem /tools/x86_64-unknown-linux-gnu/sys-include -O2 -g -O2 -DIN_GCC -fomit-frame-pointer -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o ./libgcc_s.so.1.tmp -g -O2 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o addtf3_s.o divtf3_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o floatditf_s.o floatunditf_s.o fixtfti_s.o fixunstfti_s.o floattitf_s.o floatuntitf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o getf2_s.o letf2_s.o eqtf2_s.o _divtc3_s.o _multc3_s.o _powitf2_s.o unwind-dw2_s.o unwind-dw2-fde-glibc_s.o unwind-sjlj_s.o gthr-gnat_s.o unwind-c_s.o emutls_s.o -lc && rm -f ./libgcc_s.so && if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && ln -s libgcc_s.so.1 ./libgcc_s.so
/tools/x86_64-unknown-linux-gnu/bin/ranlib libgcc.a
/tools/x86_64-unknown-linux-gnu/bin/ld: cannot find crti.o: No such file or directory

This is Linux From Scratch - Version SVN-20111013

Physically look for this file, does it exist?
if it does, then I have a workaround for ld not linking against crti.o, it has nothing to do with ld at all, it's gcc's fault, it cant access the the file directly because of the assumption that crti.o is living is /usr/lib

Can you make a symlink from /tools/lib64 to /tools/lib? then rebuild gcc and see if that helps?

$ ls -l /tools
lrwxrwxrwx 1 root root 15 Oct 26 19:49 /tools -> /mnt/lfs/tools/

$ ls -l $LFS/tools/lib64
lrwxrwxrwx 1 lfs lfs 3 Oct 26 19:50 /mnt/lfs/tools/lib64 -> lib

$ ls -l $LFS/tools/lib64/crt*
-rw-r--r-- 1 lfs lfs 3637 Oct 26 21:07 /mnt/lfs/tools/lib64/crt1.o
-rw-r--r-- 1 lfs lfs 1512 Oct 26 21:07 /mnt/lfs/tools/lib64/crti.o
-rw-r--r-- 1 lfs lfs 1108 Oct 26 21:07 /mnt/lfs/tools/lib64/crtn.o

Still the same issue
Hope this helps

Try removing the gcc-build and gcc-4.6.1 and starting over from there and append this to the top of the configure line.

Never mind. I just found out that I forgot to apply gcc-4.6.1-startfiles_fix-1.patch
Sorry for the trouble and thank you for assistance.