Dan Nicholson wrote:
> On 8/5/07, Alexander E. Patrakov <[EMAIL PROTECTED]> wrote:
>> Yes, the "ln -s lib /tools/lib64" command does appear in the log, but I
>> am afraid it doesn't do the right thing. I end up with the lib -> lib
>> symlink in the lib directory (but this is already with my "fix" - should
>> I undo it and retry?).
Yes. If you've already set up symlinks so that
/tools/lib64 -> lib
Then when you again run the command 'ln -s lib /tools/lib64' you'll end
up with
/tools/lib{,64}/lib -> lib
>> Maybe the command is executed too late (but why?
>> I don't see any mentioning of lib64 before that in the log), or "ln
>> -nsf" is needed.
No, it isn't too late, at least not when running a clean build. That
first pass of binutils doesn't link against anything in /tools (it
can't, /tools is empty), and it doesn't install anything into
/tools/lib64. However, the next package, gcc, will attempt to install
into ${PREFIX}/lib64. So before that we need to have the symlink in
place. I suppose the creation of that symlink could be moved to just
before the 'make install' command of gcc pass 1, if that is deemed more
appropriate.
> I'd suggest always using -n when making directory symlinks.
Normally, for scripting purposes, yes. And it may be useful for the CD
scripts.
But if we're trying to follow the book here precisely, then perhaps not.
At that point in the book there should definitely *not* be a
/tools/lib64 symlink. Having a -v switch is more useful there because
then you can see if the link was made incorrectly immediately.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/livecd
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
