I'm having problems with step 6.7 - Installation of Linux API headers. My output is:

root:/sources/linux-2.6.27.4# make mrproper
CLEAN include/linux/version.h
root:/sources/linux-2.6.27.4# make headers_check
CHK include/linux/version.h
UPD include/linux/version.h
HOSTCC scripts/basic/fixdep
gcc: error trying to exec '/tools/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../i686-pc-linux-gnu/bin/as': execv: No such file or directory
make[1]: *** [scripts/basic/fixdep] Error 1
make: *** [scripts_basic] Error 2

I had this problem once, started a new build, and I'm seeing this error again. When I leave the chroot envrionment, and run

user@user-desktop:/mnt/lfs/tools/i686-pc-linux-gnu/bin$ readelf -l $LFS/tools/i686-pc-linux-gnu/bin/as | grep interpreter
[Requesting program interpreter: /lib/ld-linux.so.2]

BUT

user@user-desktop:/mnt/lfs/tools$ readelf -l /tools/bin/make | grep interpreter
[Requesting program interpreter: /tools/lib/ld-linux.so.2]

This shouldn't be any surprise, since "make mrproper" worked, but why would one set of links be appropriately modified, and the other not? I plan on rebuilding [again], but I would like to be able to take extra precautions to not do this again.



To point to my own "newbism," the LFS has very discrete directions regarding line-by-line instructions, with particular emphasis on formatting. I believe I have followed everything step-by-step (truly, I wouldn't know how else to do it). For Step 5.28, installing perl, the line:

sh Configure -des -Dprefix=/tools \
-Dstatic_ext='Data/Dumper Fcntl IO POSIX'

I am not certain how to get the -Dstatic indented quite so far, so I just typed it on the following line, without the indentation. Could that be part of my problem? How is this format produced?

Thanks for any advice.

Though I could be wrong about the source of the problem, something seems to have gone wrong with your Pass 2 of Binutils in Chapter 5. That might explain why make is showing the correct interpreter but as is not. Have you tried that readelf command on any other binaries in /tools to see what you get? And you did do the test in 5.8 and didn't see any unexpected results?

As for your question about the Perl installation, the indentation doesn't actually matter, and is there in the book mainly to increase legibility and to help show (to the reader) that the -Dstatic_ext configure option is part of the command on the preceding line and not somehow a new command of its own. As long as there's at least one space (in this case, it's enough to have it before the \ on the first line), then bash should interpret everything correctly.

That being said, however, are you typing all the commands in the book in by hand? If so, when you rebuild might I recommend using copy & paste? It's much easier that way to avoid small typos and other errors that are easy to miss but that could wind up breaking things in ways that can be very difficult to diagnose.

I have tried readelf on other commands, and it does appear that most all binaries, except gcc, provides the "no such file..." output.

Thanks for the comment on the perl install. That's kinda what I figured, but I thought I would ask.

I don't recall what the output from 5.8 was, but I'm guessing I would if there had been errors.

And yes, I'm typing in everything by hand. I was trying to avoid this simply becoming a "cut and paste" exercise, as I have found this experience to be very educational, but at a minimum, I will cut and paste all the binutils (pass 2) instructions.

Thanks for the thoughts.

I understand how you feel; when I tried building my first LFS system (many years ago in the days of 4.x), I typed everything in because I thought I would somehow get much more out of it that way than if I just copy & pasted. In retrospect, though, I don't really think pasting the commands in actually detracts from the educational experience.

No matter how you do it, you still have to read all the material & instructions before and after each command, or at least you should - and it's quite possible to type something in straight from the book while giving it no more thought or reflection than if you had copied it over. Honestly, I think you get as much or as little out of LFS as you choose and as you have the patience for, and taking the time to try to understand what each command is doing doesn't necessarily mean you have to type it by hand.

In any case, it's your choice - which of course is one of the great things about LFS. Just remember that, as I mentioned, copy & pasting helps eliminate one potential source of errors, so if you do still run into problems during the rebuild you can at least feel more comfortable about narrowing down the cause.

I realize I am resurrecting an old thread; however for the benefit of others (and google):
- There was an error (or missed step) on 5.9. Binutils-2.20.1 - Pass 2
This was fixed (without having to start over), by:
-- Exiting the chroot
-- (as root): chown lfs:lfs $LFS/tools $LFS/sources
-- (as lfs) Redoing the Binutils - Pass 2 step (including cleanup)
-- (as root) chown root:root $LFS/tools $LFS/sources
-- re-entering the chroot (follow book instructions)


Also for others: I didn't realize that there was an xserver with a webbrowser on the LFS LiveCD so I was doing a lot of hand typing commands at first, which is what probably lead to my mistake. A simple 'startx' and copy and paste works wonders

Hi Erebus Bat,
I do wonder if the above is correct. It seems not/partially related to the original question, which talks about a failing make headers_check in chapter 6. Your reply seems to be focused on binutils in chapter 5. I do realize that one of the answers mentions a possible problem with binutils pass 2, but it isn't clear if that was the actual problem (it also isn't clear if this was ever resolved).

The steps you describe to change the owner and group of the sources and tools directories should have been done in chapter 3 and 4 (only the owner, not the group).

The correct settings are:
- $LFS/sources -> sticky bit is set (Chap. 3.1)
- $LFS/sources -> owner: lfs and group: root (Chap. 4.3)
- $LFS/tools -> owner: lfs and group: root

At the end of chapter 5 both owner and group of the $LFS/tools directory is set to root:root (Chap. 5.33)

Also: If you do need to revisit chapter 5 the commands need to be executed as user lfs and not root (chapter 5 is done as user lfs, chapter 6 as root).

PS: The provided links are for LFS version 6.7 and the chapter numbers might be different for other LFS versions (I do believe this thread originally talks about LFS version 6.4). The way the linux headers are installed also differ from version to version, be aware of that as well.

I realize this, I also realize that I was unclear and did not state that I was running into the exact same issue. Because I resolved it, I do know that the problem was with a binutils in pass 2.

Correct, they were done in chapter 3+4; however as the last step in chapter 5 the ownership was changed to root. The error I was encountering was with the make headers_check step in chapter 6 so I needed to revert to the permissions that were in effect in chapter 5 (otherwise the make install will fail).

You are correct, the book does not have you change the group and I did not reference the book when I did my 'fix'. At any rate it is a moot point because you do a chown -R root:root at the end of chapter 5 (and my instructions) anyway as you pointed out. So in the end you still end up with the same permissions.


This is correct, and not clear in my original post.

This is correct as well, I am using 6.7. Also I really wasn't attempting to solve the original posters problem given their whopping 5 posts they are long gone by now. I was more providing a guidance to anyone doing LFS and help them in the right direction as I had to google some to find even this thread (with no solution).

I do not intend to come across as 'snappy' to you druuna, in fact I am glad you chimed in. I just wanted to clarify your points for others that may be in the same situation and not have the same knowledge that I do. It would be a shame to have to restart that whole process for something that could (probably) be easily fixed.

Hi,
I don't find your reply snappy in any way, so don't worry about that

I replied to make sure that others don't blindly apply a solution that worked for you in a (possibly) similar situation and to give a bit more background information. The steps you mention can be useful in certain situations (although re-doing steps from chap. 5 won't be an option once one get further into chap. 6).

PS: You might consider editing your post (#5) and adding the part about executing as lfs user.