Typo in chapter 6.12.1

[skilaatara]

The '..' here doesn't make sense, as far as I can see:

ln -sv ../usr/bin/cpp /lib

It is present in both the stable 6.3 and the current development version.

[DJ Lucas]

It is a relative link. Please see 'man ls' for usage instructions.

[DJ Lucas]

Oops, that wasn't very helpful...here is why it is a relative link:

[dj@name25 ~]# ls -l /media/lfs/lib/cpp 
lrwxrwxrwx 1 root root 14 2008-10-30 00:08 /media/lfs/lib/cpp -> ../usr/bin/cpp
[dj@name25 ~]# 

[skilaatara]

But surely we don't use cpp in a non-chrooted environment after this point?

[Matthew Burgess]

As mentioned just above the 'ln' command:

Some packages expect the C preprocessor to be installed in the /lib directory. To support those packages, create this symlink: 

So, what we're doing here is providing compatibility for packages that someone may want to install after they've booted into their shiny new LFS system, and that want to call /lib/cpp instead of /usr/bin/cpp.

Hope this helps clarify things,

Matt.

[skilaatara]

Well no, that doesn't clarify why it would be a relative link. On that shiny new LFS system, presumably there is only the one "usr/lib" directory. (Not that it's important, it just looked strange to me.)

[skilaatara]

er, one "usr/bin" directory, that is.

[DJ Lucas]

There is only one '../usr/bin' that is relative to the /lib or /mnt/lfs/lib that we are in when the link is created. Think about this for just a second. Now realize, however ironic, a relative link is, in fact, more exact than an explicit link as it always points to intended target. Anyway, taken from the FHS-2.3:

If a C preprocessor is installed, /lib/cpp must be a reference to it, for historical reasons.

I doubt it makes any difference whatsoever in practice as it is only there to satisfy the aging FHS.