On 8/25/2012 8:26 PM, Jasmine Iwanek wrote: > On 2012-08-25 16:10, Eleanore Boyd wrote: >> On 8/25/2012 10:02 AM, Hadi wrote: >> >>> Hi Emerson, >>> >>> Thank your feedback, Emerson. >>> >>> I think I should correct you first. After binutils-2.22-Pass1 in >>> Chapter 5 LFS 7.1, binutils are NOT picked up from the /tools >>> directory: >>> >>> PATH= PATH=/tools/bin:/bin:/usr/bin >>> >>> In /tools/bin, there is only $LFS_TGT-* tools as following in my X86 >>> virtual box: >>> >>> lfs:/mnt/lfs$ ls tools/bin/ >>> >>> i686-lfs-linux-gnu-addr2line i686-lfs-linux-gnu-elfedit >>> i686-lfs-linux-gnu-ld i686-lfs-linux-gnu-ranlib >>> >>> i686-lfs-linux-gnu-ar i686-lfs-linux-gnu-gcc >>> i686-lfs-linux-gnu-ld.bfd i686-lfs-linux-gnu-readelf >>> >>> i686-lfs-linux-gnu-as i686-lfs-linux-gnu-gcc-4.6.2 >>> i686-lfs-linux-gnu-nm i686-lfs-linux-gnu-size >>> >>> i686-lfs-linux-gnu-c++filt i686-lfs-linux-gnu-gcov >>> i686-lfs-linux-gnu-objcopy i686-lfs-linux-gnu-strings >>> >>> i686-lfs-linux-gnu-cpp i686-lfs-linux-gnu-gprof >>> i686-lfs-linux-gnu-objdump i686-lfs-linux-gnu-strip >>> >>> Or we can use command "which is ld", it shows that ld is the host's: >>> >>> lfs:/mnt/lfs$ which is ld >>> >>> which: no is in (/tools/bin:/bin:/usr/bin) >>> >>> /usr/bin/ld >>> >>> Although in /tools/i686-lfs-linux-gnu/ there is binutils (ar/ld), >>> but /tools/i686-lfs-linux-gnu is not in the PATH. >>> >>> So it is not easy to understand "Binutils is installed first because >>> the configure runs of both GCC and Glibc perform various feature tests >>> on the assembler and linker to determine which software features to >>> enable or disable." and the tool chain constructing process. >>> >>> Hadi >> If /tools is in the path, then all subdirectories are also in the >> path. Binutils primarily contains the assembler and linker needed by >> GCC to build assembler portions of any code. >> >> Elly > Not quite true elly, configure has some code to search in certain > relative paths from the prefix, if you take a look at the build logs > you'll find lots of references like: > > checking for ld... > /mnt/lfs/tools/bin/../lib/gcc/i686-lfs-linux-gnu/4.7.1/../../../../i686-lfs-linux-gnu/bin/ld > > (That one is from gcc pass 2 in 7.2 dev chapter 5) > > If you want to test the theory, make a subdirectory under /usr/bin like > so > > bash-4.2# mkdir /usr/bin/temp > bash-4.2# echo "echo \"Well, that shouldn't have run.\"" > > /usr/bin/temp/sillyprog > bash-4.2# chmod 755 /usr/bin/temp/sillyprog > bash-4.2# sillyprog > bash: sillyprog: command not found > > you'll notice it's not found as it's not in the path: > bash-4.2# export > <snip> > declare -x PATH="/usr/bin:/bin:/usr/sbin:/sbin" > <snip> > > If subdirectories were automatically included in the path, that would > make for a bit of a security problem. > > -- > Jasmine Iwanek > > Ah. I assumed that it would have, since the binaries are in the subfolders, and not in the root of /tools.
Shows just how much I know... :) Elly -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
