cvs commit: www/lfs faq.html

jeroen at linuxfromscratch.org jeroen at linuxfromscratch.org
Tue Oct 21 10:36:49 PDT 2003


jeroen      03/10/21 11:36:49

  Modified:    faq      index.html
               lfs      faq.html
  Log:
  FAQ: added the purelfs.txt discussion about GNU Binutils vs. HJL Binutils
  
  Revision  Changes    Path
  1.62      +1 -0      www/faq/index.html
  
  Index: index.html
  ===================================================================
  RCS file: /home/cvsroot/www/faq/index.html,v
  retrieving revision 1.61
  retrieving revision 1.62
  diff -u -r1.61 -r1.62
  --- index.html	21 Oct 2003 12:58:29 -0000	1.61
  +++ index.html	21 Oct 2003 17:36:49 -0000	1.62
  @@ -92,6 +92,7 @@
   	<li id="why-not-faq"><a href="../lfs/faq.html#why-not-faq">Why not include the FAQ in the book?</a></li>
   	<li id="why-vim"><a href="../lfs/faq.html#why-vim">Why is vim in the book?</a></li>
   	<li id="why-ed"><a href="../lfs/faq.html#why-ed">Why is ed in the book?</a></li>
  +	<li id="hjl-binutils"><a href="../lfs/faq.html#hjl-binutils">Why is HJL's Binutils not in the book?</a></li>
   	<li id="why-not-package-management"><a href="../lfs/faq.html#why-not-package-management">Why isn't some package manager in the book?</a></li>
   	<li id="no-poweroff"><a href="../lfs/faq.html#no-poweroff">How do I make my machine poweroff when shut down?</a></li>
   	<li id="kernel-header-copy"><a href="../lfs/faq.html#kernel-header-copy">Why copy the kernel headers instead of linking them?</a></li>
  
  
  
  1.24      +46 -1     www/lfs/faq.html
  
  Index: faq.html
  ===================================================================
  RCS file: /home/cvsroot/www/lfs/faq.html,v
  retrieving revision 1.23
  retrieving revision 1.24
  diff -u -r1.23 -r1.24
  --- faq.html	17 Oct 2003 13:07:53 -0000	1.23
  +++ faq.html	21 Oct 2003 17:36:49 -0000	1.24
  @@ -61,6 +61,7 @@
   	<li><a href="#why-not-faq">Why not include the FAQ in the book?</a></li>
   	<li><a href="#why-vim">Why is vim in the book?</a></li>
   	<li><a href="#why-ed">Why is ed in the book?</a></li>
  +	<li><a href="#hjl-binutils">Why is HJL's Binutils not in the book?</a></li>
   	<li><a href="#why-not-package-management">Why isn't some package manager in the book?</a></li>
   	<li><a href="#no-poweroff">How do I make my machine poweroff when shut down?</a></li>
   	<li><a href="#kernel-header-copy">Why copy the kernel headers instead of linking them?</a></li>
  @@ -154,6 +155,50 @@
   				<li>Understanding ed helps with understanding vi(m) and Unix history in general.</li>
   			</ul>
   		</dd>
  +	<dt id="hjl-binutils">Why is HJL's Binutils not in the book?</dt>
  +		<dd>
  +			<p>The binutils release that you typically find on ftp.gnu.org is commonly known as the "FSF" binutils. Noted hacker H.J. Lu also makes releases out of the main CVS repository and these are commonly known as the "HJL" binutils and can usually be found on ftp.kernel.org. Debate often arises over which version to use due to the fact that most mainstream distros tend to use the HJL releases even though they are typically marked as "beta".</p>
  +			<p>Here is our interpretation of the differences between the two:-</p>
  +			<table>
  +				<tr>
  +					<th>HJL:</th>
  +					<th>FSF:</th>
  +				</tr><tr>
  +				<td>
  +					<ul>
  +						<li>for Linux OS only</li>
  +						<li>marked as "beta"</li>
  +						<li>closely follows the CVS HEAD</li>
  +						<li>usually contains the latest subtle bug fixes</li>
  +						<li>usually has latest bug fixes for non-x86 arch's</li>
  +						<li>usually a new release every time a significant bug that affects Linux gets fixed</li>
  +						<li>theoretically less stable due to newness of code</li>
  +					</ul>
  +				</td>
  +				<td>
  +					<ul>
  +						<li>supports more OS's (not only Linux)</li>
  +						<li>latest code from the stable branch of CVS</li>
  +						<li>sometimes not up-to-date WRT to the latest bleeding edge kernel, gcc and glibc subtleties</li>
  +						<li>often includes features backported from the CVS HEAD after a period of testing</li>
  +						<li>theoretically more stable</li>
  +					</ul>
  +				</td>
  +				</tr>
  +			</table>
  +	
  +			<p>You'll notice in the above points words like "usually" and "sometimes". This demonstrates how the situation can be different depending on which particular point in time you happen to be referring to. For example, from time to time there will be a new bleeding edge feature in gcc or glibc that requires support from binutils. During these times you will often hear the developers say "you must be using the latest HJL binutils version x.y.z.a.b".</p>
  +			<p>The only way to correctly choose the most appropriate release to use is to:-</p>
  +			<ul>
  +				<li>stay abreast of the issues on the project mailing lists of the core toolchain packages</li>
  +				<li>have a large dose of technical prowess and/or programming talent to understand all the issues</li>
  +				<li>test like crazy by running the test suites</li>
  +				<li>test like crazy by building full systems</li>
  +			</ul>
  +			
  +			<p>The facts of the matter are that the core toolchain packages are all very tightly bound and must be tested to ensure they work together. You basically have to build a full working distro and test every aspect of it to be fully satisfied.</p>
  +			<p>If you follow the project mailing lists of the core toolchain packages for long enough, you'll soon realise that the developers do not care much whether a particular release of "Package A" works with a particular release of "Package B". In other words, release coordination between the projects is not a priority. In reality, this means that Alan Cox is right when he says that you cannot just go to ftp.gnu.org and grab the latest of everything and always expect it to just work.</p>
  +		</dd>
   	<dt id="why-not-package-management">Why isn't some package manager in the book?</dt>
   		<dd>
   			<p>Package management - beyond that provided by tarballs and makefiles - is beyond the scope of the book. If nothing else does, the number of different "solutions" should hint at some of the reasons.</p>
  @@ -335,7 +380,7 @@
   			<p>You're most likely getting this while building bash in Chapter 5 of the LFS Book. The problem is most likely your mount options. You probably have a line in /etc/fstab like:</p>
   			<code>/dev/hda10  /mnt/lfs  ext2  user  1  2</code>
   			<p>'user' is the mount flag, and it's the problem. To quote from the mount man page:</p>
  -			<blockquote>user:  Allow  an  ordinary  user to mount the file system. This  option  implies  the options noexec, nosuid, and nodev (unless overridden by subsequent options, as in the option line user,exec,dev,suid).</blockquote>
  +			<cite>user:  Allow  an  ordinary  user to mount the file system. This  option  implies  the options noexec, nosuid, and nodev (unless overridden by subsequent options, as in the option line user,exec,dev,suid).</cite>
    			<p>So change the line in /etc/fstab like this:</p>
   			<code>/dev/hda10  /mnt/lfs  ext2  defaults  1  2</code>
   		</dd>
  
  
  



More information about the website mailing list