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:
> Chaps,
> 
> 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
> headers).

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
there.

> 
> 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 :)
> 
> Cheers,




More information about the lfs-dev mailing list