lfs bugs and/or changes

James Iwanek chthon at chthon-uk.com
Sat May 10 16:08:44 PDT 2003

Greg Schafer wrote:

> 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
> reports.
>> 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
> :-)

its more like 8/9%

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

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