lfs bugs and/or changes

Zack Winkles winkie at linuxfromscratch.org
Fri May 9 18:44:37 PDT 2003


I've been doin' a bunch of LFS work lately, and I've run into a number
of bugs in the current CVS book (stuff that's been around since before
the PLFS merge). Some of them are rehashes of things I've said before,
others things that I don't think have been brought up yet. Here goes:

1. Remove the vim patch. It hasn't been needed since 3.2.1. It was only
   needed so that the patch script wouldn't barf on the way gcc complained
   about include paths. It's no longer needed.

2. Vim manpage. We create the vi->vim symlink, so shouldn't it have a
   corresponding man page? It would give us a chance to educate the users
   about a tiny bit of man syntax, and education is always a good thing. A
   command such as the following would suffice:
	echo '.so man1/vim.1' > /usr/share/man/man1/vi.1

3. Using <package_name>/build instead of ../<package_name>-build. This
   is mostly just an aesthetic thing that was brought up a few weeks back.
   I dunno, it just feels cleaner.

4. For our system GCC, we use separate tarballs (gcc-{core,g++,...}, but
   for GCC 2.95.3, we use the "fullfat" (as Ian calls it) tarball, which
   just seems somewhat wrong. Either use fullfat for both or neither.

5. Remove procinfo. What does it even do? Has anybody ever done anything
   with it?

6. H J Lu's binutils (/me hides under a rock). I don't think I need to
   elaborate on this one.

7. We need to run "make" in the automake directory. The lack of that
   command is a remnant from automake-1.4, when make was about as
   useless as a turd. Now it actually does something, so we should run
   it. It could be said that it's not necessary, but I argue that it's
   not necessary for ANYTHING technically.

8. Patch a few things for the POSIX compliance (read as: breakage) that
   will come with Glibc 2.3.3. It's not currently an issue, but it will
   be. Let's be prepared. Patches to GCC 3.2.3 and Linux 2.4.20 are
   attached.

9. make configure-host for binutils. Again, this isn't strictly
   necessary, but the first binutils 2.14 release came out a few days
   back, and it requires make configure-host, at least in the first
   build of chapter 5. We're going to add it eventually and everybody
   knows it, so let's not put it off.

10. Build proper bzip2 libraries. We build the correct libbz2.so, as the
   Makefile adds -fPIC by itself, but then we simply run make, which adds
   all this PIC code into a static libbz2.a, which is completely
   unnecessary and unoptimal. In doing this, we slow down anything that
   uses libbz2.a by 20%. The ONLY thing needed to build a proper libbz2.a
   and libbz2.so is to make clean right after make -f Makefile-libbz2_so.
   The make clean leaves bzip2-shared and libbz2.so* intact, so there is
   no harm, only gain.

11. Build proper zlib libraries. The reasoning behind this is the exact
   same as that of libbz2, but the procedure is a bit more involved. The
   following commands do what we need:
	CFLAGS="$CFLAGS -fPIC" ./configure --prefix=/usr --shared
	make
	make install
	make clean
	./configure --prefix=/usr
	make
	make install

12. Remove the notes about make in chapter 6. Make 3.80 fixes the bug
   that caused previous version of make to get strange permissions
   (setgid kmem afair). Put simply, it's not needed anymore.

/me takes a deep breath.

OK. I'm sure there's stuff I'm forgetting, but this is my current list
of craps in LFS.

Later,
Zack

-------------- next part --------------
A non-text attachment was scrubbed...
Name: linux-2.4.20.patch.bz2
Type: application/octet-stream
Size: 945 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20030509/43313a42/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc-3.2.3-posix.patch.bz2
Type: application/octet-stream
Size: 1857 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20030509/43313a42/attachment-0001.obj>


More information about the lfs-dev mailing list