Document host system requirements

[alexander@…]

Right now, the book only says that a kernel >= 2.6.2 compiled with gcc >= 3.0 is required. That's certainly insufficient, the build will fail e.g. with sed < 4.0.

Please collect the required versions of host tools from READMEs of the Chapter 5 packages that depend on host tools.

[chris@…]

Here's what I have so far...

bash binutils >=2.13 bzip2 coreutils gcc >=3.0 glibc gzip make >=3.79.1 patch sed tar

Also a note should be added that users will have to install "dev" or "devel" versions of these packages if they are available on the host.

[chris@…]

I've got a couple more...

gcc >=3.2 gawk >=3.0

binutils also suggests gzip 1.2.4, bzip 1.0.2 and tar 1.12, but I don't know if it's necessary to worry about these...AFAIK they aren't "required" to build any of the packages.

Also, if these host system requirements are going to be updated, perhaps each package's list of dependencies should also be looked at. The first thing I just noticed is that binutils pass1 says it "depends on" gettext, but "--disable-nls" is used. Unless of course it's because every program that it *can* it use is listed there (since LFS, unlike BLFS, doesn't separate dependencies into "Required", "Optional"...).

[chris@…]

Some more additions...

The requirement of gcc >= 3.2 is mentioned in the glibc docs, but as patrakov reminded me in the the chat room, glibc is built *after* the first pass of the new gcc, so that just leaves gcc >= 3.0. Here's the list I have so far...

bash binutils >= 2.13 bzip2 coreutils diffutils findutils >= 4.1.20 gawk >= 3.0 gcc >= 3.0 glibc gzip make >= 3.79.1 patch perl sed >= 4.0 tar

[chris@…]

One potential problem with this list...I don't know about the gcc >= 3.0 "requirement" - I simply noted that the book already mentions that a kernel compiled with gcc >= 3.0, and I assumed your version of gcc itself should also be >= 3.0. However, it's difficult to test since I can't even compile 2.95.3, and don't feel like installing SuSE just to check the older gcc included there. Can anyone who knows more than I do validate (or destroy, whichever the case may be) my assumption about the required gcc version?

[Jeremy Huntwork]

(In reply to comment #4)

Can anyone who knows more than I do validate (or destroy, whichever the case may be) my assumption about the required gcc version?

When we first changed over to 2.6 kernels plus NPTL, a kernel compiled with 2.95 would produce a working system, however the glibc testsuites would invariably fail. I don't recall if other brokenness existed with the resultant system. I don't think the devs at that time were too concerned with finding out either. It was easier to just push the minimal requirement up. Since a 2.6 kernel was necessary to build the new LFS with NPTL, it didn't seem too stringent to also require that that kernel be built with gcc>=3.0.

[chris@…]

(In reply to comment #3)

Just went through the documentation again...here's the list again, with some corrections...

bash binutils >= 2.13 bzip2 >= 1.0.2 coreutils diffutils >= 2.7 findutils >= 4.1.20 gawk >= 3.0 gcc >= 3.0 glibc grep gzip >= 1.2.4 make >= 3.79.1 patch >= 2.5.4 perl 5 (though glibc says perl is only needed if running the testsuite, and gcc says it's just needed if modifying the source code) sed >= 4.0 tar >= 1.12

I know the book lists m4 as a dependency for binutils, but I don't see where it's using it. I renamed /usr/bin/m4 temporarily, and it built successfully, and the testsuite ran without a single failure. The only place I see m4 mentioned in the toolchain package docs is for gcc, and that's only listed as being needed if you're modifying the source code.

BTW does anyone know where to find any kind of documentation on binutils? The source tarball has virtually nothing as far as installation instructions and building prerequisites - just generic instructions (basically just "run ./configure --options && make && make install...").

[chris@…]

(In reply to comment #6)

I know the book lists m4 as a dependency for binutils, but I don't see where it's using it. I renamed /usr/bin/m4 temporarily, and it built successfully, and the testsuite ran without a single failure. The only place I see m4 mentioned in the toolchain package docs is for gcc, and that's only listed as being needed if you're modifying the source code.

A little more...I've noticed that binutils is the only package in Chapter 5 that is listed as "depending on" m4. I also see that there are only 6 packages (besides binutils) that say they need m4 in Chapter 6 - autoconf, automake, bison, flex, kbd, and module-init-tools. So, if binutils turns out to not really need m4, m4 could be dropped from Chapter 5 entirely, as all of the other Chapter 6 packages that use m4 must be installed *after* m4 anyway. Of course it would be nice if someone with much more technical knowledge than I gave their input on this, since as I mentioned before, binutils installation documentation is a little hard to come by...

[alexander@…]

Only HJL Binutils depend on m4. FSF binutils don't need m4, indeed.

AFAIK m4 was added to Chapter 5 only because of HJL binutils.

[dbn.lists@…]

Two that always seems to bite people on lfs-support:

bison flex

-devel packages. Don't know about versions.

[chris@…]

Yes, but those are only for the current stable book. They aren't needed for the development book.

[chris@…]

Just started building a current LFS system with an LFS 3.3 installation (minor exception being findutils - I used 4.1.20 instead of 4.1 - couldn't find the patch for 4.1). Actually I did a very minimal build with *only* the packages I listed here (minus perl). Of course more testing is welcome to see if this actually results in the same final system as building from a current host, but it seems to me to be working so far (all toolchain tests have passed in Chapter 6 on the system I'm building). Here's another updated list of Host System Reqs., based on the versions used in LFS 3.3...

bash >= 2.05a binutils >= 2.12 bzip2 >= 1.0.2 coreutils >= 5.0 (or sh-utils >= 2.0, textutils >= 2.0, and fileutils >= 4.1) diffutils >= 2.7 findutils >= 4.1.20 gawk >= 3.0 gcc >= 2.95.3 glibc >= 2.2.5 grep >= 2.5 gzip >= 1.2.4 make >= 3.79.1 patch >= 2.5.4 sed >= 3.02 tar >= 1.12

[Matthew Burgess]

From ticket #1732, Dan Nicholson makes a good point that we need to mention in the Host Requirements section the fact that the LFS book is only tested on x86 boxes and that the CLFS project caters for other architectures.

[Jeremy Huntwork]

How accurate is this last list of reqs? I'd like to drop this in, but just want to verify that there haven't been any new discoveries since.

[Chris Staub]

I just went through the documentation one more time, and I can only see a couple things. I have again been building a current LFS dev system using an LFS 3.3 system (with *only* the packages listed above). About the only differences I can see are that GCC docs say to use tar >= 1.14 to unpack the tarball but the LFS 3.3 system has tar 1.13 that seems to work fine, and Glibc docs say diffutils >= 2.7, but I have only been able to find, and use, 2.8{,.1}, so we may as well just put diffutils >= 2.8.

[Jeremy Huntwork]

Comments or opinions on this layout?

​http://linuxfromscratch.org/~jhuntwork/html-lfs-trunk/prologue/hostreqs.html

[Chris Staub]

I think that's good. The only thing I would add is there should also be note saying you may need the "-dev" or "-devel" versions of those packages as well, if your host provides them.

[bdubbs@…]

The overall idea is good but I don't care for the layout. Instead, I would say:

Your host system should have the following software with the minimum versions indicated. This should not be an issue for most modern Linux distributions.

And then just list the packages:

• Bash-2.05a
• Binutils-2.12
• Bzip2-1.0.2
• etc

Also, the sentence

This second option can also be seen as a gauge of your current Linux skills. If this second requirement is too steep, then the LFS book will not likely be much use to you at this time.

Seems a little harsh.

Finally, the section number is 4, but there is another 4 (Chapter 4).

This may be for manuel, but I'd number the sections in the preface i., ii., iii., iv., etc.

[manuel@…]

Plus the minimum versions required, I think that should be noted also that for some packages (Binutils, GCC, and maybe others) the maximum supported version is the one used to create the LFS system in the book that the user is reading.

That could to prevent issues when trying to build an stable LFS book using a host newest than that LFS book.

[Chris Staub]

I don't think that's really an issue very much. Even if there are problems (such as building LFS 6.1 with a GCC4 host system) it's usually fixable just by finding a patch. The real problems are usually just specific host systems, not simply newer package versions. Besides, it doesn't seem realistic to expect the user to find a host system using package versions <= what's in the LFS book when LFS stable is over 8 months old (yes, I know 6.1.1 is newer than that, but most package versions are unchanged from 6.1). Adding a comment that hosts with newer versions than what's in the stable LFS book are not "supported" puts pressure on us not to let the current stable book get out of date (though that's probably not a bad thing...).

[Jeremy Huntwork]

I agree with what Chris has said, but as a sort of compromise, how does this look?

​http://linuxfromscratch.org/~jhuntwork/html-lfs-trunk/prologue/hostreqs.html

[manuel@…]

Instead of "not recommended" we could to say just "not tested", that is most true that that packages versions was released after the book release.

Pd: the TRAC mails don't go again to the lfs-book list. That must be fixed.

[Jeremy Huntwork]

As far as "not tested" to me, that would imply that every version between the minimum and the one in the book is tested, which I don't think would necessarily be true, either. Personally, I'm happy to leave it as it currently is and go with not recommended.

[Jeremy Huntwork]

Closing, as the original intent of the ticket is completed.

[Jeremy Huntwork]

Done as of r7538

[bdubbs@…]

Instead of saying not recommended, you can say not tested.

The spacing for the bullets still seems a little large, but if you add the recomendation below, it may be OK.

How does a new user know what version of the packages currently loaded are? RPM? Other package manager? I'd suggest putting a line in each section saying what to run to check the version number. For instance, gcc --version