lfs bugs and/or changes

Greg Schafer gschafer at zip.com.au
Sat May 10 15:47:16 PDT 2003

On Fri, May 09, 2003 at 09:44:37PM -0400, Zack Winkles wrote:
> 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.

True that it's no longer needed i.e. since gcc-3.2.1 it doesn't break the
build. But any package that specifically includes /usr/local/include in it's
"-I" directives is inherently broken and I always try to patch them.
Therefore my preference would be to leave the patch in.

> 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

Ok, it's a one liner. Lets put it in to shut Zack up.
/me runs :-)

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

Gcc list has talked about this in the last few days. As has been mentioned
before, gcc docs say "highly recommend" not do this. Current way feels clean
enough for me.

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

real men have always used the full tarball :-)
(apologies to any real women in the audience!)

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

This smacks of "I don't want this so everybody else shouldn't have it".
Please, think of the bigger picture. LFS book is for everyone. You have the
power to remove the pkg in your own builds. While the utilities are not
often used, they are useful in a base system. Gerard has seen fit to include
the package since the year dot so lets respect his preference.

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

It should be a case-by-case basis. Current FSF appears to work with current
gcc. This could change of course. Bleeding edge and power users will always
use the HJL release.

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

I've always run make anyway and thus haven't noticed. But you appear to be
correct here.

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

Has anyone tested the ENV VAR solution yet? I'm currently working on other
stuff and thus haven't played with glibs cvs lately. If simply setting an
ENV VAR fixes it then that would seem a much cleaner solution to me. Sure,
the fixes will need to happen upstream eventually. Start sending bug

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

This will error out with current FSF 2.13.x builds. Lets put it in when it's
actually needed, not right now.

> 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

Agreed on the above 2 points. But I wonder how you arrived at the 20% claim

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


Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list