Stealth wrote: > If you are one of those growing tired of my mail don't read it, just > delete it. Save us both some aggravation. If you really want to > help and not insult, then read on. Blame Trent for this opening > paragraph.
This was unecessary. > I have arrived at the exact same place as before with an error when > running this: > > gcc -dumpspecs | sed '[EMAIL PROTECTED]/lib/ld-linux.so.2@/tools&@g' \ > > `dirname $(gcc -print-libgcc-file-name)`/specs > > sed: can't > read /mnt/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/4.1.2/specs: > No such file or directory Actually, this is different than the last time. Notice that the path it can't read is now in /mnt/lfs/tools, not /usr. This is very important, and it's a good thing. You had two problems last time. The first was that the 'gcc -dumpspecs' command was still using a gcc in /usr/bin. The second problem is the same one you're hitting this time, which is likely some very slight mis-typing on your part with the above command. > running 'which gcc' prints /tools/bin/gcc Excellent. > echo $PATH > > PATH=/tools/bin:/bin:/usr/bin Excellent. > the specs file is still here: > > /mnt/lfs/sources/gcc-build/gcc/specs This is probably happening because something in the above command is wrong. > gcc -dumpspecs | sed '[EMAIL PROTECTED]/lib/ld-linux.so.2@/tools&@g' \ > `dirname $(gcc -print-libgcc-file-name)`/specs > > Where is this specs file supposed to be? If the command above were to succeed, you'd have a new file called 'specs' here: /mnt/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/4.1.2/specs And inside that file, all lines that began with '/lib/ld-linux.so.2' would be changed to '/tools/lib/ld-linux.so.2'. Let's break the command down a bit, because it's really 4 commands wrapped into one: 1. gcc -dumpspecs (try it and see what it does) 2. sed '[EMAIL PROTECTED]/lib/ld-linux.so.2@/tools&@g' (don't try this by itself, it won't work) 3. gcc -print-libgcc-file-name (try this one too, by itself) 4. dirname [the output of number 3.] So, this is what happens. The gcc -dumpspecs command is run and it's output is piped to sed. (If you don't know what that means, look up Pipeline in Wikipedia). Sed transforms the contents of the first command and adds /tools to the beginning of lines matching /lib/ld-linux.so.2. When sed is done, it is going to spit its results to a file, because we use the '>' for output redirection. (Look up output redirection in google). The rest of the command, from dirname on, assembles the path where the new file will be put. Start from the inside out, $(gcc ..) will return the results of the command inside the parentheses as a value. The backticks '`' will do essentially the same thing, so dirname will run against the value returned by the gcc command inside the parentheses. The end result should give you a path that looks like: /mnt/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/4.1.2/specs So that is where sed should be trying to write the new specs file. If this command is failing, look _very_ carefully to ensure that you are typing the command exactly as the book is says. Also, make sure that the directory '/mnt/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/4.1.2' exists and that the lfs user can write to it. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
