#3605 closed task (invalid)
Section 6.17.1, directory has unnecessary ..
Reported by: | Ryan P.C. McQuen | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 7.6 |
Component: | Book | Version: | SVN |
Severity: | normal | Keywords: | gcc |
Cc: |
Description
Quoting section 6.17.1: """ Install the package:
make install
Some packages expect the C preprocessor to be installed in the /lib directory. To support those packages, create this symlink:
ln -sv ../usr/bin/cpp /lib
""" Should be listed as '/usr/bin/cpp', since running make install is done in /sources/gcc-build.
Thank you.
Change History (13)
comment:1 by , 10 years ago
comment:3 by , 10 years ago
You are supposed to do what the book says, and book didn't mention that at all. Symlink is correct, no matter from what directory you are in when it's being run. [insert your fav. search engine here] for "Relative Symbolic Links".
comment:4 by , 10 years ago
But doesn't removing the '..' have the same effect? The command is confusing because ../usr/bin is not a valid directory from /sources/gcc-build.
comment:5 by , 10 years ago
It does have the same effect. But do note that ../usr/bin is a valid directory from /lib, which is the second parameter of the ln -sf ... command. That's why the directory you are in doesn't matter. If you have any further questions, please mail lfs-support mailing list. Ticket system is not a place for such things.
comment:6 by , 10 years ago
We can close it then. But isn't the point of LFS to be about learning and minimalism? To that end, wouldn't writing the command without '..' be better for the end user?
comment:7 by , 10 years ago
It is about learning, and in coming here and asking about it, you've learned about another valid ln syntax. Therefore, I'd say that goal was accomplished.
comment:8 by , 10 years ago
Well enough then. : -)
It is strange to me that ln follows relativity differently than other unix commands. As you were.
comment:10 by , 10 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Since you mention that the point of LFS is learning, and you didn't know how is it the command was correct, and I suppose now you know - that's why command stays there - to show how things can be done differently. Again I repeat, search online for "Relative Symbolic Links".
comment:11 by , 10 years ago
How can these both be valid? -f is 'force', so I'm curious how one knows to go from the CWD, while the other goes from the last argument. Is it because the directory would be invalid if relative to the second argument?
ln -sfv ../../lib/$(readlink /usr/lib/libncursesw.so) /usr/lib/libncursesw.so
ln -sv ../usr/bin/cpp /lib
Thank you.
comment:12 by , 10 years ago
Please take support questions to lfs-support@… mailing list (you need to be subscribed first).
If you typed "readlink /usr/lib/libncursesw.so", you'd see that it prints "libncursesw.so.5". Since libncursesw.so.5 is moved to /lib, symlink needs to be corrected so that libncursesw.so.5 points to ../../lib/libncursesw.so.5 instead of libncursesw.so.5. -f is used to overwrite old libncursesw.so file since it existed before the command was run.
Command is correct. Symlink is relative to /lib - it would become /lib/../usr/bin/cpp which is the same as /usr/bin/cpp.