Initial testing build notes
Jeremy Utley (-J-), LFS Staff
jeremy at linuxfromscratch.org
Wed Sep 1 02:34:03 PDT 2004
On Wed, 2004-09-01 at 02:13, matthew.burgess at syntegra.com wrote:
> Here's a few notes I made during last night's largely successful build
> attempt. Note that the build only went as far as finishing 'automake' in
> chapter 6 before it got to 01:30 and I forced myself off to bed! I should be
> able to finish the build tonight, so more notes may follow tomorrow.
> 1. /tools/lib/libtcl8.4.so appears to be installed with the wrong
> permissions. This is triggered by attempting the 'strip' commands at the end
> of chapter 5:
> 'strip --strip-debug /tools/lib/libtcl8.4.so' results in a permission denied
> error. Changing the permissions to 644 fixes this. I could have sworn we
> used to do this, but couldn't see anything in the current book last night.
Standard for shared libs is 755 - but i'd say this is a non-issue, since
obviously the lib works for what we need it for (building expect), and
/tools is a throw-away tree anyway.
> 2. At the start of chapter 6, we fake mount the virtual filesystems. I
> couldn't see any point before that which suggested I should be root when
> doing this, although I presumed I'd have to be anyway (I feared the "only
> root can mount ???" message). Is it assumed prior knowledge that you have to
> be root to perform these mounts, or is a note warranted (like the one given
> for performing the 'chroot' command shortly afterwards)?
Everything in chatper 6 should be performed as root, perhaps we should
make a note in the introduction to chapter 6 that we should return from
the "lfs" user back to root.
> 3. 'mount -t devpts -o gid=4,mode=620 none /dev/pts' resulted in 'warning:
> can't open /etc/fstab: No such file or directory'. Now, this is just a
> warning, the filesystem was mounted correctly, but I saw no mention of this
> in the book. Again, is it assumed that the reader will understand that it's
> just a warning, or should we mention that it's just a harmless message?
This one we should probably note as well.
> 4. I got 2 testsuite failures in perl. Unfortunately my build scripts
> summarily delete the build trees so I don't know the points of failure at the
> moment. Have you seen anything similar, or should I be expecting to see a
> "clean bill of health" from perl?
Seems like the last time I ran that testsuite, it passed. Can you
perhaps find out where the failures were at?
> And finally some more minor things we might want to do _after_ LFS-6.0:
> 5. In the installation of linux-libc-headers, we change the permissions of
> the files and directories using explicit 'chmod' commands. Can we prepare a
> patch to the Makefiles to get them to install with the correct permissions,
> or is there a reason why Mariusz installs them with different permissions
> than us out of the box?
linux-libc-headers doesn't have a makefile, so it's either do it before
or after copying.
> 6. During the installation of iproute2 I saw a lot of warnings from the use
> of /usr/include/linux/socket.h instead of <sys/socket.h>. Without having
> even looked at the iproute2 sources, it would appear to be a trivial patch to
> get it to include the correct header. As iproute2 is actively maintained,
> seeing this patch incorporated shouldn't take too long (assuming I'm not
> misunderstanding something, and iproute2 really _does_ need the linux
Jim could answer this better than I could, but iproute2 does interact
pretty deeply with kernel features - our current version requires a
2.6.8 kernel to even work properly, so that might be why it's looking
> All in all, it's looking good so far - and yes, Jeremy, I will be expecting
> the cluebat out for some, if not all of the points above :)
More information about the lfs-dev