- Merge the following from the English version:

r43797 -> r43804	head/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml
This commit is contained in:
Ryusuke SUZUKI 2014-03-18 10:02:13 +00:00
parent ce11f90485
commit b9d88f336c
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=44277

View file

@ -3,7 +3,7 @@
The FreeBSD Documentation Project
The FreeBSD Japanese Documentation Project
Original revision: r43797
Original revision: r43804
$FreeBSD$
-->
<chapter xmlns="http://docbook.org/ns/docbook"
@ -2529,16 +2529,15 @@ Script done, &hellip;</screen>
</sect2>
<sect2 xml:id="updating-questions">
<title>質問ですか?</title>
<title>よくある質問</title>
<qandaset>
<qandaentry>
<question>
<para>変更が行なわれたら、その度にシステムの再構築が必要になるのでしょうか?</para>
</question>
<variablelist>
<varlistentry>
<term>変更が行なわれたら、
その度にシステムの再構築が必要になるのでしょうか?</term>
<answer>
<para>それは変更の性質によるので、なんとも言えません
<listitem>
<para>それは変更の内容によります
たとえば、<application>svn</application> を実行したとき、
次にあげるようなファイルが更新されていたとします。</para>
@ -2553,107 +2552,80 @@ Script done, &hellip;</screen>
<command>make all install</command> を行ってください。
しかし、たとえば <filename>src/lib/libc/stdlib</filename>
のような大きな変更が行なわれた場合には、
システム全体を再構築するか、
少なくとも静的にリンクされているものを作り直す必要があります。</para>
システム全体を再構築することを検討してください。</para>
<para>結局のところ、
どの時点で現在のシステムをアップグレードするかはあなたが決めることです。
2 週間ごとにシステムを再構築し、その 2 週間の変更を取り込むユーザもいますし、
<para>2 週間ごとにシステムを再構築して、
その 2 週間分の変更を取り込むユーザもいますし、
変更のあった部分だけ再構築し、
すべての依存関係を確かめたいと考えるユーザもいます。</para>
すべての依存関係を確かめたいと考えるユーザもいます。
それらはどのくらいの頻度でアップグレードしたいか、
そして &os.stable;&os.current;
のどちらを追いかけているのかにもよります。</para>
</listitem>
</varlistentry>
<para>それらはどのくらいの頻度でアップグレードしたいか、
そして &os.stable;&os.current; のどちらを追いかけているのかによります。</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>signal 11<indexterm>
<varlistentry>
<term>どうして signal 11<indexterm>
<primary>signal 11</primary>
</indexterm>
(もしくは他のシグナル番号) のエラーがたくさん出て
コンパイルが失敗します。何が起こっているんでしょうか?</para>
</question>
コンパイルが失敗するのでしょうか?</term>
<answer>
<listitem>
<para>これは通常、ハードウェアに問題があることを示しています。
システムの再構築は、ハードウェアに対する負荷耐久試験を行なうための
有効な手段の一つで、メモリに関係する問題がよく報告されます。
その大部分は、
不可解な異常終了となることで発見されます。</para>
world の再構築は、
ハードウェア (特にメモリ)
に対する負荷耐久試験を行なうための有効な手段です。
本当にこの問題によるものかどうかは、
<application>make</application>
をもう一度実行し、異なる段階で異常終了が発生するか、
ということから確認できます。</para>
<para>本当にこの問題によるものかどうかは、<application>make</application>
をもう一度実行し、
異なる段階で異常終了が発生するか、ということから確認できます。</para>
<para>このエラーに対応するには、マシンの部品を交換して、
<para>このエラーに対応するには、RAM を始めとして、
マシンの部品をメモリから交換して、
どの部分が悪いのかを調べてみてください。</para>
</answer>
</qandaentry>
</listitem>
</varlistentry>
<qandaentry>
<question>
<para>終了したら <filename>/usr/obj</filename>
を削除してもかまいませんか?</para>
</question>
<varlistentry>
<term>終了したら <filename class="directory">/usr/obj</filename>
を削除してもかまいませんか?</term>
<answer>
<para>一言で答えるなら「削除しても構わない」です。</para>
<para><filename>/usr/obj</filename> には、
<listitem>
<para>このディレクトリには、
コンパイルの段階で生成された
すべてのオブジェクトファイルが含まれています。
通常 <command>make buildworld</command> の最初の段階では、
このディレクトリを削除して新しくつくり直すようになっています。
構築終了後も <filename>/usr/obj</filename>
を保存しておいても、あまり意味はありません。
削除すれば、だいたい 2&nbsp;GB
削除すれば、だいたい 2GB
のディスクスペースを解放することができます。</para>
</listitem>
</varlistentry>
<para>良く理解をしているユーザであれば、
この段階を省略して <command>make buildworld</command>
を行なうことができます。
こうすると、ほとんどのソースは再コンパイルされないため、
構築はかなり高速化されます。
これは裏をかえせば、デリケートな依存関係の問題によって、
システムの構築が奇妙な失敗に終わる可能性があるということです。
&os; メーリングリストではしばしば、構築の失敗が、
この段階の省略によるものだということを理解せずに
不満の声をあげる人がいます。</para>
</answer>
</qandaentry>
<varlistentry>
<term>構築を中断した場合、
その構築を途中から再開することはできますか?</term>
<qandaentry>
<question>
<para>構築を中断した場合、その構築を途中から再開することはできますか?</para>
</question>
<answer>
<listitem>
<para>それは、問題が起こるまでに、
どれだけの作業を終えているかによって変わります。</para>
<para>一般的に <command>make buildworld</command> は、
&man.gcc.1;&man.make.1; まどの基本的なツールや、
どれだけの作業を終えているかによります。
一般的に <command>make buildworld</command> は、
基本的なツールや、
システムライブラリの新しいコピーを作成します。
その後、これらのツールやライブラリがインストールされてから、
自分自身の再構築に使われ、もう一度、インストールされます。
&man.ls.1;&man.grep.1;
といった標準的なユーザプログラムを含むシステム全体が、
その新しいシステムファイルを用いて作り直されます。</para>
システムの残りの部分がその新しいシステムファイルを用いて作り直されます。</para>
<para>再構築の最終段階では、
まったく安全に次のようにすることができます。</para>
まったく安全に以下のコマンドを実行することができます。
これは、前回の <command>make buildworld</command>
の作業をやり直しません。</para>
<screen><emphasis>&hellip; fix the problem &hellip;</emphasis>
&prompt.root; <userinput>cd /usr/src</userinput>
<screen>&prompt.root; <userinput>cd /usr/src</userinput>
&prompt.root; <userinput>make -DNO_CLEAN all</userinput></screen>
<para>
これは、前回の <command>make buildworld</command>
の作業をやり直しません。
</para>
<para>次のメッセージ</para>
<screen>--------------------------------------------------------------
@ -2663,72 +2635,41 @@ Building everything..
<para><command>make buildworld</command> の出力にある場合には、
上のようにしてもほとんど悪影響が現れることはありません。</para>
<para>もしこのメッセージがないとか、よく分からないという場合には、
<para>もしこのメッセージがない場合には、
安全を確保し、後悔するようなことがないよう、
システムの再構築を最初からやり直しましょう。</para>
</answer>
</qandaentry>
</listitem>
</varlistentry>
<qandaentry>
<question>
<para>どのようにすれば make world を高速化できますか?</para>
</question>
<varlistentry>
<term>make world を高速化できますか?</term>
<answer>
<itemizedlist>
<listitem>
<para>シングルユーザモードで動かしてください。</para>
</listitem>
<listitem>
<para>いくつかの方法で build world のプロセスを高速化できます。
たとえば、全体のプロセスは、
シングルユーザモードで動かすことで高速になります。
しかしながら、この方法では、プロセスが完了するまで、
ユーザがシステムにアクセスすることはできません。</para>
<listitem>
<para><filename>/usr/src</filename>
<filename>/usr/obj</filename>
を、異なるディスク上の別のファイルシステムに置いてください。
また可能ならば、
異なるディスクコントローラに接続されたディスクを使ってください。</para>
</listitem>
<para>ファイルシステムを注意深く設計したり、
ZFS データセットを使うことでも変わります。
<filename class="directory">/usr/src</filename>
<filename class="directory">/usr/obj</filename>
を、異なるディスク上の別のファイルシステムに置くことを検討してください。
また可能ならば、
異なるディスクコントローラに接続された異なるディスクにファイルシステムを置いてください。
<filename class="directory">/usr/src</filename>
をマウントする時には、
最後にアクセスされた時刻の書き込みを抑制するように、
<option>noatime</option>
オプションを付けてマウントしてください。
もし、<filename
class="directory">/usr/src</filename> が、
独立したファイルシステムではないときには、
<option>noatime</option> オプションで、<filename
class="directory">/usr</filename>
を再マウントしてください。</para>
<listitem>
<para>さらに高速化するには、これらのファイルシステムを
&man.ccd.4; を使って、
複数のディスク上に置いてください。</para>
</listitem>
<listitem>
<para><filename>/etc/make.conf</filename>
<quote>NO_PROFILE=true</quote> をセットして、
プロファイル版の作成を無効化してください。</para>
</listitem>
<listitem>
<para>&man.make.1;
<option>-j<replaceable>n</replaceable></option>
を指定して、複数のプロセスを並列に実行させてください。
これは、単一のプロセッサでも複数のプロセッサでも、
同様に恩恵を得ることができます。</para>
</listitem>
<listitem>
<para><filename>/usr/src</filename>
のあるファイルシステムを、<option>noatime</option>
オプションを付けてマウントもしくは再マウントしてください。
これは、そのファイルシステムにおいて、
最後にアクセスされた時刻の書き込みを抑制します。
おそらく、この情報が必要になることはないでしょう。</para>
<screen>&prompt.root; <userinput>mount -u -o noatime /usr/src</userinput></screen>
<warning>
<para>上の例は、
<filename>/usr/src</filename>
自身が独立したファイルシステムであることを想定しています。
もし <filename>/usr</filename>
の一部である場合には、
かわりに適切なマウントポイントを指定すしてください。</para>
</warning>
</listitem>
<listitem>
<para><filename>/usr/obj</filename>
のあるファイルシステムを、<option>async</option>
オプションをつけてマウントもしくは再マウントしてください。
@ -2757,25 +2698,22 @@ Building everything..
バックアップをきちんと取っておきましょう。</para>
</warning>
<screen>&prompt.root; <userinput>mount -u -o async /usr/obj</userinput></screen>
<para><filename>/etc/make.conf</filename>
<quote>NO_PROFILE=true</quote> をセットして、
プロファイル版の作成を無効化してください。</para>
<warning>
<para>もし <filename>/usr/obj</filename>
自身がファイルシステムでない場合には、
適切なマウントポイントを指すように、
上の例の名前を置き換えてください。</para>
</warning>
<para>&man.make.1;
<option>-j<replaceable>n</replaceable></option>
を指定して、複数のプロセスを並列に実行させてください。
これは、単一のプロセッサでも複数のプロセッサでも、
同様に恩恵を得ることができます。</para>
</listitem>
</itemizedlist>
</answer>
</qandaentry>
</varlistentry>
<qandaentry>
<question>
<para>なにか悪いことがあったらどうすればいいですか?</para>
</question>
<varlistentry>
<term>なにか悪いことがあったらどうすればいいですか?</term>
<answer>
<listitem>
<para>自分の環境に前のビルドの余計なゴミが残っていないことをはっきりと確認してください。</para>
<screen>&prompt.root; <userinput>chflags -R noschg /usr/obj/usr</userinput>
@ -2793,9 +2731,9 @@ Building everything..
<para>まだ問題があれば、エラーと <command>uname -a</command>
の出力を &a.questions; に送ってください。
設定についてさらに質問されても答えられるよう用意してください!</para>
</answer>
</qandaentry>
</qandaset>
</listitem>
</varlistentry>
</variablelist>
</sect2>
</sect1>