Environment does not get cleared before chapter 5 starts

[rodolfo@…]

I had problems while configuring glibc in the first pass of chapter 5 (it was looking for the kernel headers in the wrong place) and after some while I discovered that the environment variable CPATH that's defined in my host isn't being unset. So I'd suggest to add the line

<variable name="CPATH"></variable>

around line 41 of LFS.xml. That solved my problem.

PS: Why the environment doesn't get cleaned up and just the important variables get in, as per the LFS book?

[kpfleming@…]

I had never even heard of CPATH before you entered this bug, nor does the book make any reference to it. Given that, it's not surprising that the current LFS profile does not make any attempt to override it. I can't see any point in adding a specific CPATH override in the profile; if we did that, we'd have to override every variable that could possibly cause a problem, which is a very long list.

However, I can see some value in modifying the runit.sh script to use the same "exec env -i ... " technique that the book uses to clear out the environment before starting nALFS. Alternatively, the chapter 5 portion of the LFS profile could use the <root> element to chroot to "/", which would mean no effective change in the root path at all, but the environment would be cleared because the <root> element has that as a documented side effect.

[rodolfo@…]

As you might have already looked up, gcc adds the CPATH path list to its header path list. So, it's as important as CFLAGS, CXXFLAGS, etc. I don't remember if nALFS also clears LIBRARY_PATH, another variable similar to CPATH, but dealing with libraries search path. Their problem is that they're not very common. I have those set here because I wanted to add ~/include and ~/lib into the search list. And unfortunately (misconfiguration) I had /usr/include also in CPATH.

The best solution (I think) would be clearing up the environment at start. Could this be made when nALFS switch to the user lfs with the action 'user'? That's where the problem begins, because the book says to do a 'su - lfs' which clears up the environment, but nALFS doesn't.

[Thomas]

Kevin,

I had a few spare moments and decided to look at this, and it could be done both ways, although the latter solution seems to work the best, plus we could get rid of the variable blocks that unset certain variables.

It requires a slight modification of the PATH variable to be like it is in the book, and adding the TERM and HOME variables, and the environment is cleared out and reinitialized as it is in the book.

[kpfleming@…]

I believe the <root> method is the best way to go, because it doesn't require any changes outside the profile itself. The other method requires that the profile be run via the script, and if the user does not do that we are exposed to these unusual problems. I don't have any opposition to the way you've proposed implementing it.

Note to Rodolfo: Your assumption that using <user> would clear the enviroment was in error. In the LFS book, the only reason that "su - lfs" clears the environment is because the book has the user create a .bash_profile for the lfs user that forcibly clears the environment. Normal usage of "su" does not do that, and the <user> element in ALFS profiles won't either, because that would be a drastic change and likely would break existing profiles that rely on the current behavior.