From owner-doc-jp@jp.freebsd.org  Sun Oct 31 15:41:22 1999
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id PAA67904;
	Sun, 31 Oct 1999 15:41:22 +0900 (JST)
	(envelope-from owner-doc-jp@jp.FreeBSD.org)
Received: from sv01.geocities.co.jp (sv01.geocities.co.jp [210.153.89.155])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id PAA67899
	for <doc-jp@jp.freebsd.org>; Sun, 31 Oct 1999 15:41:21 +0900 (JST)
	(envelope-from hrs@geocities.co.jp)
Received: from mail.geocities.co.jp (mail.geocities.co.jp [210.153.89.137]) by sv01.geocities.co.jp (8.9.3+3.2W/3.7W) with ESMTP id PAA17654 for <doc-jp@jp.freebsd.org>; Sun, 31 Oct 1999 15:41:21 +0900 (JST)
Received: from mail.hrs.jp (sutnmax1-ppp45.ed.noda.sut.ac.jp [133.31.173.55]) by mail.geocities.co.jp (1.3G-GeocitiesJ-3.3) with ESMTP id PAA07688 for <doc-jp@jp.freebsd.org>; Sun, 31 Oct 1999 15:41:18 +0900 (JST)
Message-Id: <199910310641.PAA07688@mail.geocities.co.jp>
Received: from localhost (alph.hrs.jp [192.168.0.10])
	by mail.hrs.jp (8.9.3/3.7W/DomainMaster) with ESMTP id PAA77435
	for <doc-jp@jp.freebsd.org>; Sun, 31 Oct 1999 15:36:21 +0900 (JST)
	(envelope-from hrs@hrs.jp)
To: FreeBSD-doc-jp <doc-jp@jp.freebsd.org>
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Date: Sun, 31 Oct 1999 15:35:34 +0900
From: Hiroki Sato <hrs@geocities.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 399
Reply-To: doc-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+990727
X-Sequence: doc-jp 6823
Subject: [doc-jp 6823] <handbook> cutting-edge/chapter.sgml 1.30 -> 1.32 (part 7/7)
Errors-To: owner-doc-jp@jp.freebsd.org
Sender: owner-doc-jp@jp.freebsd.org
X-Originator: hrs@geocities.co.jp

$B:4F#!wEl5~M}2JBg3X$G$9!#(B

$B<7$DL\!#(B

+    <sect2>
+      <title/Questions?/
+
+      <qandaset>
+	<qandaentry>
+	  <question>
+	    <para>Do I need to re-make the world for every change?</para>
+	  </question>
+
+	  <answer>
+            <para>There is no easy answer to this one, as it depends on the
+	      nature of the change.  For example, I have just run CVSup, and
+	      it has shown the following files as being updated since I last
+	      ran it;</para>
+      
+	    <screen><filename>src/games/cribbage/instr.c</filename>
+<filename>src/games/sail/pl_main.c</filename>
+<filename>src/release/sysinstall/config.c</filename>
+<filename>src/release/sysinstall/media.c</filename>
+<filename>src/share/mk/bsd.port.mk</filename></screen>
+
+	    <para>There is nothing in there that I would re-make the world
+	      for.  I would go to the appropriate sub-directories and
+	      <command>make all install</command>, and that's about it.  But
+	      if something major changed, for example
+	      <filename>src/lib/libc/stdlib</filename> then I would either
+	      re-make the world, or at least those parts of it that are
+	      statically linked (as well as anything else I might have added
+	      that is statically linked).</para>
+      
+	    <para>At the end of the day, it is your call.  You might be happy
+	      re-making the world every fortnight say, and let changes
+	      accumulate over that fortnight.  Or you might want to re-make
+	      just those things that have changed, and are confident you can
+	      spot all the dependencies.</para>
+      
+	    <para>And, of course, this all depends on how often you want to
+	      upgrade, and whether you are tracking -stable or
+	      -current.</para>
+	  </answer>
+	</qandaentry>
+
+	<qandaentry>
+	  <question>
+	    <para>My compile failed with lots of signal 12 (or other signal
+	      number) errors.  What has happened?</para>
+	  </question>
+
+	  <answer>
+	    <para>This is normally indicative of hardware problems.
+	      (Re)making the world is an effective way to stress test your
+	      hardware, and will frequently throw up memory problems.  These
+	      normally manifest themselves as the compiler mysteriously dying
+	      on receipt of strange signals.</para>
+      
+	    <para>A sure indicator of this is if you can restart the make and
+	      it dies at a different point in the process.</para>
+      
+	    <para>In this instance there is little you can do except start
+	      swapping around the components in your machine to determine
+	      which one is failing.</para>
+	  </answer>
+	</qandaentry>
+
+	<qandaentry>
+	  <question>
+	    <para>Can I remove <filename>/usr/obj</filename> when I have
+	      finished?</para>
+	  </question>
+	  
+	  <answer>
+	    <para>That depends on how you want to make the world on future
+	      occasions.</para>
+      
+	    <para><filename>/usr/obj</filename> contains all the object files
+	      that were produced during the compilation phase.  Normally, one
+	      of the first steps in the <quote/make world/ process is to
+	      remove this directory and start afresh.  In this case, keeping
+	      <filename>/usr/obj</filename> around after you have finished
+	      makes little sense, and will free up a large chunk of disk space
+	      (currently about 150MB).</para>
+      
+	    <para>However, if you know what you are doing you can have
+	      <quote/make world/ skip this step.  This will make subsequent
+	      builds run much faster, since most of sources will not need to
+	      be recompiled.  The flip side of this is that subtle dependency
+	      problems can creep in, causing your build to fail in odd ways.
+	      This frequently generates noise on the FreeBSD mailing lists,
+	      when one person complains that their build has failed, not
+	      realising that it is because they have tried to cut
+	      corners.</para>
+      
+	    <para>If you want to live dangerously then make the world, passing
+	      the <makevar>NOCLEAN</makevar> definition to make, like
+	      this:</para>
+
+	    <screen>&prompt.root; <userinput>make -DNOCLEAN world</userinput></screen>
+	  </answer>
+	</qandaentry>
+
+	<qandaentry>
+	  <question>
+	    <para>Can interrupted builds be resumed?</para>
+	  </question>
+
+	  <answer>
+	    <para>This depends on how far through the process you got before
+	      you found a problem.</para>
+
+	    <para><emphasis>In general</emphasis> (and this is not a hard and
+	      fast rule) the <quote>make world</quote> process builds new
+	      copies of essential tools (such as &man.gcc.1;, and
+	      &man.make.1;>) and the system libraries.  These tools and
+	      libraries are then installed.  The new tools and libraries are
+	      then used to rebuild themselves, and are installed again. The
+	      entire system (now including regular user programs, such as
+		&man.ls.1; or &man.grep.1;) is then rebuilt with the new
+	      system files.</para>
+
+	    <para>If you are at the last state, and you know it (because you
+	      have looked through the output that you were storing) then you
+	      can (fairly safely) do</para>
+
+	    <screen><emphasis>&hellip; fix the problem &hellip;</emphasis>
+&prompt.root; <userinput>cd /usr/src</userinput>
+&prompt.root; <userinput>make -DNOCLEAN all</userinput></screen>
+
+	    <para>This will not undo the work of the previous
+	      <quote>make world</quote>.</para>
+
+	    <para>If you see the message
+
+	      <screen>--------------------------------------------------------------
+Building everything..
+--------------------------------------------------------------</screen>
+
+	      in the <quote>make world</quote> output then it is
+	      probably fairly safe to do so.</para>
+	    
+	    <para>If you do not see that message, or you are not sure, then it
+	      is always better to be safe than sorry, and restart the build
+	      from scratch.</para>
+	  </answer>
+	</qandaentry>
+
+	<qandaentry>
+	  <question>
+	    <para>Can I use one machine as a <emphasis/master/ to upgrade lots
+	      of machines (NFS)?</para>
+	  </question>
+
+	  <answer>
+	    <para>People often ask on the FreeBSD mailing lists whether they
+	      can do all the compiling on one machine, and then use the
+	      results of that compile to <command>make install</command> on to
+	      other machines around the network.</para>
+      
+	    <para>This is not something I have done, so the suggestions below
+	      are either from other people, or deduced from the
+	      Makefiles.</para>
+	    
+	    <para>The precise approach to take depends on your version of
+	      FreeBSD</para>
+	    
+	    <para>You must still upgrade <filename>/etc</filename> and
+	      <filename>/dev</filename> on the target machines after doing
+	      this.</para>
+	    
+	    <para>For 2.1.7 and below, Antonio Bemfica
+	      suggested the following approach:</para>
+
+	    <screen>Date: Thu, 20 Feb 1997 14:05:01 -0400 (AST)
+From: Antonio Bemfica &lt;bemfica@militzer.me.tuns.ca&gt;
+To: freebsd-questions@freebsd.org
+Message-ID: &lt;Pine.BSI.3.94.970220135725.245C-100000@militzer.me.tuns.ca&gt;
+
+Josef Karthauser asked:
+
+&gt; Has anybody got a good method for upgrading machines on a network
+
+First make world, etc.  on your main machine
+Second, mount / and /usr from the remote machine:
+
+main_machine% mount remote_machine:/   /mnt
+main_machine% mount remote_machine:/usr /mnt/usr
+
+Third, do a 'make install' with /mnt as the destination:
+
+main_machine% make install DESTDIR=/mnt
+
+Repeat for every other remote machine on your network.   It works fine
+for me.
+     
+Antonio</screen>
+
+	    <para>This mechanism will only work (to the best of my knowledge)
+	      if you can write to <filename>/usr/src</filename> on the NFS
+	      server, as  the <maketarget>install</maketarget> target in 2.1.7
+	      and below needed to do this.</para>
+	    
+	    <para>Midway between 2.1.7 and 2.2.0 the <quote>reinstall</quote>
+	      target was committed.  You can use the approach exactly as
+	      outlined above for 2.1.7, but use <quote>reinstall</quote>
+	      instead of <quote>install</quote>.</para>
+
+	    <para>This approach <emphasis>does not</emphasis> require write
+	      access to the <filename>/usr/src</filename> directory on the NFS
+	      server.</para>
+
+	    <para>There was a bug introduced in this target between versions
+	      1.68 and 1.107 of the Makefile, which meant that write access to
+	      the NFS server <emphasis>was</emphasis> required.  This bug was
+	      fixed before version 2.2.0 of FreeBSD was released, but may be an
+	      issue of you have an old server still running -stable from this
+	      era.</para>
+
+	    <para>For version 2.2.5 and above, you can use the
+	      <quote>buildworld</quote> and <quote>installworld</quote>
+	      targets.  Use them to build a source tree on one machine, and
+	      then NFS mount <filename>/usr/src</filename> and
+	      <filename>/usr/obj</filename> on the remote machine and install
+	      it there.</para>
+	  </answer>
+	</qandaentry>
+
+	<qandaentry>
+	  <question>
+	    <para>How can I speed up making the world?</para>
+
+	    <itemizedlist>
+	      <listitem>
+		<para>Run in single user mode.</para>
+	      </listitem>
+	      
+	      <listitem>
+		<para>Put the <filename>/usr/src</filename> and
+		  <filename>/usr/obj</filename> directories on separate
+		  filesystems held on separate disks.  If possible, put these
+		  disks on separate disk controllers.</para>
+	      </listitem>
+	      
+	      <listitem>
+		<para>Better still, put these filesystems across separate
+		  disks using the <quote>ccd</quote> (concatenated disk
+		  driver) device.</para>
+	      </listitem>
+	      
+	      <listitem>
+		<para>Turn off profiling (set <quote>NOPROFILE=true</quote> in
+		  <filename>/etc/make.conf</filename>).  You almost certainly
+		  do not need it.</para>
+	      </listitem>
+	      
+	      <listitem>
+		<para>Also in <filename>/etc/make.conf</filename>, set
+		  <quote>CFLAGS</quote> to something like <quote>-O
+		    -pipe</quote>. The optimisation <quote>-O2</quote> is much
+		  slower, and the optimisation difference between
+		  <quote>-O</quote> and <quote>-O2</quote> is normally
+		  negligible.  <quote>-pipe</quote> lets the compiler use
+		  pipes rather than temporary files for communication, which
+		  saves disk access (at the expense of memory).</para>
+	      </listitem>
+	      
+	      <listitem>
+		<para>Pass the <option>-j&lt;n&gt;</option> option to make (if
+		  you are running a sufficiently recent version of FreeBSD) to
+		  run multiple processes in parallel.  This helps regardless
+		  of whether you have a single or a multi processor
+		  machine.</para>
+	      </listitem>
+	      
+	      <listitem><para>The filesystem holding
+		  <filename>/usr/src</filename> can be mounted (or remounted)
+		  with the <quote>noatime</quote> option.  This stops the time
+		  files in the filesystem were last accessed from being
+		  written to the disk.  You probably do not need this
+		  information anyway.
+
+		  <note>
+		    <para><quote>noatime</quote> is in version 2.2.0 and
+		      above.</para>
+		  </note>
+		  
+		  <screen>&prompt.root; <userinput>mount -u -o noatime /usr/src</userinput></screen>
+		  
+		  <warning>
+		    <para>The example assumes <filename>/usr/src</filename> is
+		      on its own filesystem.  If it is not (if it is a part of
+		      <filename>/usr</filename> for example) then you will
+		      need to use  that filesystem mount point, and not
+		      <filename>/usr/src</filename>.</para>
+		  </warning>
+		</para>
+	      </listitem>
+	      
+	      <listitem>
+		<para>The filesystem holding <filename>/usr/obj</filename> can
+		  be mounted (or remounted) with the <quote>async</quote>
+		  option.  This causes disk writes to happen asynchronously.
+		  In other words, the write completes immediately, and the
+		  data is written to the disk a few seconds later.  This
+		  allows writes to be clustered together, and can be a
+		  dramatic performance boost.</para>
+
+		<warning>
+		  <para>Keep in mind that this option makes your filesystem
+		    more fragile.  With this option there is an increased
+		    chance that, should power fail, the filesystem will be in
+		    an unrecoverable state when the machine restarts.</para>
+	   
+		  <para>If <filename>/usr/obj</filename> is the only thing on
+		    this filesystem then it is not a problem.  If you have
+		    other, valuable data on the same filesystem then ensure
+		    your backups are fresh before you enable this
+		    option.</para>
+		</warning>
+		
+		<screen>&prompt.root; <userinput>mount -u -o async /usr/obj</userinput></screen>
+		
+		<warning>
+		  <para>As above, if <filename>/usr/obj</filename> is not on
+		    its own filesystem, replace it in the example with the
+		    name of the appropriate mount point.</para>
+		</warning>
+	      </listitem>
+	    </itemizedlist>
+	  </question>
+	</qandaentry>
+      </qandaset>
+    </sect2>
+
+    <sect2>
+      <title>Contributors</title>
+      
+      <para>The following people have contributed to this document in some
+	form or another.  Either by directly suggesting alterations and
+	improvements, pointing out errors, or by their messages to the FreeBSD
+	mailing lists, from which I have shamelessly cribbed information.  My
+	thanks to them.</para>
+
+      <itemizedlist>
+	<listitem>
+	  <para>Antonio Bemfica,
+	    <email>bemfica@militzer.me.tuns.ca</email></para>
+	</listitem>
+
+	<listitem>
+	  <para>Sue Blake, <email>sue@welearn.com.au</email></para>
+	</listitem>
+	
+	<listitem>
+	  <para>Brian Haskin, <email>haskin@ptway.com</email></para>
+	</listitem>
+	
+	<listitem>
+	  <para>Kees Jan Koster, <email>kjk1@ukc.ac.uk</email></para>
+	</listitem>
+	
+	<listitem>
+	  <para>A Joseph Kosy, <email>koshy@india.hp.com</email></para>
+	</listitem>
+	
+	<listitem>
+	  <para>Greg Lehey, <email>grog@lemis.com</email></para>
+	</listitem>
+	
+	<listitem>
+	  <para>Wes Peters, <email>softweyr@xmission.com</email></para>
+	</listitem>
+	
+	<listitem>
+	  <para>Joseph Stein, <email>joes@wstein.com</email></para>
+	</listitem>
+
+	<listitem>
+	  <para>Studded, <email>studded@dal.net</email></para>
+	</listitem>
+	
+	<listitem>
+	  <para>Axel Thimm,
+	    <email>Axel.Thimm@physik.fu-berlin.de</email></para>
+	</listitem>
+	
+	<listitem>
+	  <para>Matthew Thyer,
+	    <email>Matthew.Thyer@dsto.defence.gov.au</email></para>
+	</listitem>
+      </itemizedlist>
+    </sect2>

--
| $B:4F#(B $B9-@8!wEl5~M}2JBg3X(B <hrs@geocities.co.jp>
|                         mailto:j7397067@ed.noda.sut.ac.jp
|
