<sect1 id="ch05-gcc-pass2">
<!--
<title>Installing GCC-&gcc-version; - Pass 2</title>
-->
<title>GCC-&gcc-version; のインストール</title>
<?dbhtml filename="gcc-pass2.html" dir="chapter05"?>

<!--
<screen>Estimated build time:           &gcc-time-tools-pass2;
Estimated required disk space:  &gcc-compsize-tools-pass2;</screen>
-->
<screen>推定構築時間:           &gcc-time-tools-pass2;
推定必要ディススペース  &gcc-compsize-tools-pass2;</screen>


<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>

<sect2>
<!--
<title>Re-installation of GCC</title>
-->
<title>GCC の再インストール</title>

<!--
<para>The tools required to test GCC and Binutils are installed now (Tcl, Expect
and DejaGnu). We can continue on rebuilding GCC and Binutils, link them against
the new Glibc, and test them properly. One thing to note, however, is that these
test suites are highly dependent on properly functioning pseudo terminals (PTYs)
which are provided by your host distribution. These days, PTYs are most commonly
implemented via the <emphasis>devpts</emphasis> file system. You can quickly
check if your host system is set up correctly in this regard by performing a
simple test:</para>
-->
<para>これでGCC と Binutils をテストするのに必要なツール（ Tcl, Expect 及び DejaGnu ）がインストールされました。
GCC と Binutils の再インストール、それらの新しい Glibc へのリンク、そして、それらをきちんとテストすることが続けられます。
しかし一つ注意することは、これらのテストスイートはホストシステムから提供される正しく機能する擬似ターミナル（ PTYs ）に強く依存します。
最近では一般的に PTYs は <emphasis>devpts</emphasis> ファイルシステムによって提供されています。
この点でお使いのホストシステムが正しく設定されているかどうか、簡単なテストを行なうことですぐにチェックすることができます。</para>

<screen><userinput>expect -c "spawn ls"</userinput></screen>

<!--
<para>If you receive the message:</para>
-->
<para>もしも</para>

<blockquote><screen>The system has no more ptys.  Ask your system administrator to create more.</screen></blockquote>

<!--
<para>Your host distribution is not set up for proper PTY operation. In this
case there is no point in running the test suites for GCC and Binutils until you
are able to resolve the issue. You can consult the LFS Wiki at
<ulink url="http://wiki.linuxfromscratch.org/"/> for more information on how to
get PTYs working.</para>
-->
<para>というメッセージが出るなら、お使いのホストディストリビューションは適切な PTY 運用について設定されていません。
この場合は、問題を解決できるようになるまで GCC と Binutils へのテストは意味がありません。
PTYs をどうやって動かすようにするかについての情報は <ulink url="http://wiki.linuxfromscratch.org/"/> の LFS Wiki で調べることができます。</para>

<!--
<para>Unpack all three GCC tarballs (-core, -g++, and -testsuite) in one and the
same working directory. They will all unfold into a single
<filename>gcc-&gcc-version;/</filename> subdirectory.</para>
-->
<para>三つの GCC tarball (-core, -g++ 及び -testsuite) を全て一つの同じ作業ディレクトリに解凍します。
それらは全て一つの <filename>gcc-&gcc-version;/</filename> サブディレクトリに展開されます。</para>

<!--
<para>First correct one problem and make an essential adjustment:</para>
-->
<para>初めに一つの問題を正し、それから極めて重要な調整をします。</para>

<screen><userinput>patch -Np1 -i ../&gcc-nofixincludes-patch;
patch -Np1 -i ../&gcc-specs-patch;</userinput></screen>

<!--
<para>The first patch disables the GCC "fixincludes" script.  We mentioned this
briefly earlier, but a slightly more in-depth explanation of the fixincludes 
process is warranted here.  Under normal circumstances, the GCC fixincludes
script scans your system for header files that need to be fixed.  It might find
that some Glibc header files on your host system need to be fixed, fix them and
put them in the GCC private include directory.  Then, later on in
<xref linkend="chapter06"/>, after we've installed the newer Glibc, this
private include directory would be searched before the system include
directory, resulting in GCC finding the fixed headers from the host system,
which would most likely not match the Glibc version actually used for the LFS
system.</para>
-->
<para>最初のパッチは GCC "fixincludes" スクリプトを無効にします。先に述べましたが、ここでは fixincludes の過程についてのもう少し立ち入った説明をするのが当然でしょう。
普通、GCC fixincludes スクリプトは修正しなくてはいけないヘッダーファイルについて、お使いのホストシステムを調べます。
お使いのホストシステムで修正されなければいけない Glibc のヘッダーファイルを見つけると、それらを修正し、そして GCC 用のインクルードディレクトリに置きます。
それから、後ほど<xref linkend="chapter06"/>で新しい Glibc をインストールしたあと、このインクルードディレクトリはシステムインクルードディレクトリよりも前に調べられます。
GCC がホストシステムからの修正されたヘッダを探すことになり、LFS システムで実際に使われる Glibc のバージョンに間違いなく適合しないものになるでしょう。</para>

<!--
<para>The last patch changes GCC's default location of the dynamic linker
(typically <filename>ld-linux.so.2</filename>). It also removes
<filename class="directory">/usr/include</filename> from GCC's include search
path. Patching now rather than adjusting the specs file after installation
ensures that our new dynamic linker gets used during the actual build of GCC.
That is, all the final (and temporary) binaries created during the build will
link against the new Glibc.</para>
-->
<para>最後のパッチは GCC の動的リンカ（通常 <filename>ld-linux.so.2</filename> ）のデフォルトの場所を変更します。
これはまた GCC の include 検索パスから <filename class="directory">/usr/include</filename> を取り除きます。
インストールのあとにスペックファイルを調整するよりも、今パッチを当てることは、新しい動的リンカが GCC の実際の構築の間に使われることを保証します。
すなわち、構築の間に作成されたすべての最終的な（および暫定的な）バイナリ類が新しい Glibc に対してリンクされることになります。</para>

<!--
<important><para>These patches are <emphasis>critical</emphasis> in ensuring a
successful overall build. Do not forget to apply them.</para></important>
-->
<important><para>これらのパッチは構築全体がうまく行くようにするため、とても重要です。パッチをあてるのを忘れないで下さい。</para></important>

<!--
<para>Create a separate build directory again:</para>
-->
<para>再び別の構築ディレクトリを作ります。</para>

<screen><userinput>mkdir ../gcc-build
cd ../gcc-build</userinput></screen>

<!--
<para>Before starting to build GCC, remember to unset any environment
variables that override the default optimization flags.</para>
-->
<para>GCC の構築を始める前に、デフォルトの最適化フラグを書きかえるすべての環境変数を外すことを思いだしてください。</para>

<!--
<para>Now prepare GCC for compilation:</para>
-->
<para>それではコンパイルのために GCC を準備します。</para>

<screen><userinput>../gcc-&gcc-version;/configure --prefix=/tools \
&nbsp;&nbsp;&nbsp;&nbsp;--with-local-prefix=/tools \
&nbsp;&nbsp;&nbsp;&nbsp;--enable-clocale=gnu --enable-shared \
&nbsp;&nbsp;&nbsp;&nbsp;--enable-threads=posix --enable-__cxa_atexit \
&nbsp;&nbsp;&nbsp;&nbsp;--enable-languages=c,c++</userinput></screen>

<!--
<para>The meaning of the new configure options:</para>
-->
<para>新しい設定オプションの意味</para>

<itemizedlist>
<!--
<listitem><para><userinput>&#045;&#045;enable-threads=posix</userinput>: This enables
C++ exception handling for multi-threaded code.</para></listitem>
-->
<listitem><para><userinput>--enable-threads=posix</userinput>: このオプションはマルチスレッドコードのための C++ 例外処理を有効にします。</para></listitem>

<!--
<listitem><para><userinput>&#045;&#045;enable-__cxa_atexit</userinput>: This option
allows use of __cxa_atexit, rather than atexit, to register C++ destructors for
local statics and global objects and is essential for fully standards-compliant
handling of destructors. It also affects the C++ ABI and therefore results in
C++ shared libraries and C++ programs that are interoperable with other Linux
distributions.</para></listitem>
-->
<listitem><para><userinput>--enable-__cxa_atexit</userinput>: このオプションはローカルスタティックとグローバルオブジェクトのデストラクタを登録するのに atexit ではなく __cxa_atexit を使うようにさせ、完全に標準準拠の処理とするのにとても重要です。
これはまた、C++ ABI にも影響し、その結果 C++ 共有ライブラリと C++ プログラムは他の Linux ディストリビューション間で共通に利用できるようになります。</para></listitem>

<!--
<listitem><para><userinput>&#045;&#045;enable-clocale=gnu</userinput>: This option ensures
the correct locale model is selected for the C++ libraries under all
circumstances. If the configure script finds the <emphasis>de_DE</emphasis>
locale installed, it will select the correct model of <emphasis>gnu</emphasis>.
However, people who don't install the <emphasis>de_DE</emphasis> locale, run the
risk of building ABI incompatible C++ libraries due to the wrong locale model of
<emphasis>generic</emphasis> being selected.</para></listitem>
-->
<listitem><para><userinput>--enable-clocale=gnu</userinput>: このオプションはあらゆる状況下に置いて C++ ライブラリへの正しいロケールモデルが選ばれるようにします。
設定スクリプトがインストールされた <emphasis>de_DE</emphasis> ロケールを見つけると、<emphasis>gnu</emphasis> の正しいモデルを選択します。
しかし、<emphasis>de_DE</emphasis> ロケールをインストールしない人たちは、間違って <emphasis>generic</emphasis> ロケールモデルが選択されるために、ABI 互換性のない C++ ライブラリを構築する危険を冒すことになります。</para></listitem>

<!--
<listitem><para><userinput>&#045;&#045;enable-languages=c,c++</userinput>: This option is
needed to ensure that both C and C++ compilers are built.</para></listitem>
-->
<listitem><para><userinput>--enable-languages=c,c++</userinput>: このオプションは C 及び C++ の両方の構築を確実にするのに必要です。</para></listitem>
</itemizedlist>

<!--
<para>Compile the package:</para>
-->
<para>パッケージをコンパイルします。</para>

<screen><userinput>make</userinput></screen>

<!--
<para>There is no need to use the <userinput>bootstrap</userinput> target now,
as the compiler we're using to compile this GCC was built from the exact same
version of the GCC sources we used earlier.</para>
-->
<para>この GCC をコンパイルするのに使っているコンパイラは、以前使った GCC のソースと全く同じバージョンのものから構築されたので、<userinput>ブートストラップ</userinput>ターゲットを今使う必要はありません。</para>

<!--
<note><para>It's worth pointing out that running the GCC test suite here
is considered not as important as running it in
<xref linkend="chapter06"/>.</para></note>
-->
<note><para>GCC テストスイートをここで実行するのは<xref linkend="chapter06"/>で実行することほど重要ではないと考えられることを指摘しておきます。</para></note>

<!--
<para>Test the results:</para>
-->
<para>結果をテストします。</para>

<screen><userinput>make -k check</userinput></screen>

<!--
<para>The <userinput>-k</userinput> flag is used to make the test suite run
through to completion and not stop at the first failure. The GCC test suite is
very comprehensive and is almost guaranteed to generate a few failures. To get
a summary of the test suite results, run this:</para>
-->
<para><userinput>-k</userinput> フラグは、テストスイートを最初の失敗で停止しないで最後まで実行するために使われます。
GCC テストスイートはとても包括的なものなので、いくつかの失敗がつきものです。
テストスイートの大まかな結果のを知るために、このコマンドを実行します。</para>
 
<screen><userinput>../gcc-&gcc-version;/contrib/test_summary | more</userinput></screen>

<!--
<para>You can compare your results to those posted to the gcc-testresults
mailing list for similar configurations to your own. For an example of how
current GCC-&gcc-version; should look on i686-pc-linux-gnu, see
<ulink url="http://gcc.gnu.org/ml/gcc-testresults/2003-08/msg01612.html"/>.</para>
-->
<para>あなたの同じような設定について、gcc-testresults メーリングリストに投稿されたものと自分の結果を比較できます。
現在の GCC-&gcc-version; が i686-pc-linux-gnu をどのように見るかという事の例は、<ulink url="http://gcc.gnu.org/ml/gcc-testresults/2003-08/msg01612.html"/> を見て下さい。</para>

<!--
<para>Note that the results contain:</para>
-->
<para>この結果は以下のものを含んでいることを記しておきます。</para>

<screen>* 1 XPASS (unexpected pass) for g++
* 1 FAIL (unexpected failure) for g++
* 2 FAIL for gcc
* 26 XPASS's for libstdc++</screen>

<!--
<para>The unexpected pass for g++ is due to the use of
<userinput>&#045;&#045;enable-__cxa_atexit</userinput>. Apparently not all platforms
supported by GCC have support for "__cxa_atexit" in their C libraries, so this
test is not always expected to pass.</para>
-->
<para>g++ で出ている unexpected pass は <userinput>--enable-__cxa_atexit</userinput> を使ったからです。
明らかに、GCC によってサポートされる全てのプラットフォームがその C ライブラリで "__cxa_atexit" をサポートをしているわけではないので、このテストはいつも成功するわけではありません。</para>

<!--
<para>The 26 unexpected passes for libstdc++ are due to the use of
<userinput>&#045;&#045;enable-clocale=gnu</userinput>, which is the correct choice on
Glibc-based systems of versions 2.2.5 and above. The underlying locale support
in the GNU C library is superior to that of the otherwise selected "generic"
model (which may be applicable if for instance you were using Newlibc, Sun-libc
or whatever libc). The libstdc++ test suite is apparently expecting the
"generic" model, hence those tests are not always expected to pass.</para>
-->
<para>libstdc++ で出ている 26 の unexpected pass は <userinput>--enable-clocale=gnu</userinput> の使用によるもので、これはバージョン 2.2.5 以上の Glibc ベースのシステムでは正しい選択です。
GNU C ライブラリでの基本的なロケールのサポートは、その他の場合に選ばれる "generic" モデル（これらは例えば Newlibc や Sun-libc, 何とかlibc を使っているとしたら当てはまるかも知れません）よりも優先します。
libstdc++ テストスイートは "generic" モデルを期待しているようなので、そのためこれらのテストがいつも成功するわけではありません。</para>

<!--
<para>Unexpected failures often cannot be avoided. The GCC developers are
usually aware of them but haven't yet gotten around to fixing them. In short,
unless your results are vastly different from those at the above URL, it is safe
to continue on.</para>
-->
<para>unexpected failuers はしばしば避けられません。GCC の開発者達は普段それらに気がついていますが、まだ修正するに至っていません。
手短に言うと、結果が上の URL にあるものから大きく異なっていない限り、続けても安全です。</para>

<!--
<para>And finally install the package:</para>
-->
<para>それでは最後にパッケージをインストールします。</para>

<screen><userinput>make install</userinput></screen>

<!--
<note><para>At this point it is strongly recommended to repeat the sanity check
we performed earlier in the chapter. Refer back to
<xref linkend="ch05-locking-glibc"/> and repeat the check. If the results are
wrong, then most likely you forgot to apply the above mentioned GCC Specs
patch.</para></note>
-->
<note><para>この時点で、この章の初めの方で行なった完成度テストを繰り返すことを強く勧めます。
<xref linkend="ch05-locking-glibc"/>の節を再び参照し、チェックを繰り返します。もし結果が悪ければ、上述した GCC Specs パッチをあてるのを忘れているというのが最もありそうな原因でしょう。</para></note>

</sect2>

</sect1>

