| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223 | 
							- <?xml version="1.0" encoding="ISO-8859-1"?>
 
- <!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
 
-   <!ENTITY % general-entities SYSTEM "../general.ent">
 
-   %general-entities;
 
- ]>
 
- <sect1 id="ch-tools-glibc" role="wrap">
 
- <title>Glibc-&glibc-version;</title>
 
- <?dbhtml filename="glibc.html"?>
 
- <indexterm zone="ch-tools-glibc">
 
- <primary sortas="a-Glibc">Glibc</primary>
 
- <secondary>tools</secondary></indexterm>
 
- <sect2 role="package"><title/>
 
- <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/glibc.xml" xpointer="xpointer(/sect1/sect2[1]/para[1])"/>
 
- <segmentedlist>
 
- <segtitle>&buildtime;</segtitle>
 
- <segtitle>&diskspace;</segtitle>
 
- <seglistitem><seg>11.8 SBU</seg><seg>800 MB</seg></seglistitem>
 
- </segmentedlist>
 
- <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/glibc.xml" xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
 
- </sect2>
 
- <sect2 role="installation">
 
- <title>Installation of Glibc</title>
 
- <para>This package is known to behave badly when you change its default
 
- optimization flags (including the <parameter>-march</parameter> and
 
- <parameter>-mcpu</parameter> options). Therefore, if you have defined any
 
- environment variables that override default optimizations, such as CFLAGS and
 
- CXXFLAGS, we recommend un-setting them when building Glibc.</para>
 
- <para>Basically, compiling Glibc in any other way than the book suggests
 
- is putting the stability of your system at risk.</para>
 
- <para>The Glibc documentation recommends building Glibc outside of the source
 
- directory in a dedicated build directory:</para>
 
- <screen><userinput>mkdir ../glibc-build
 
- cd ../glibc-build</userinput></screen>
 
- <para>Next, prepare Glibc for compilation:</para>
 
- <screen><userinput>../glibc-&glibc-version;/configure --prefix=/tools \
 
-     --disable-profile --enable-add-ons=nptl --with-tls \
 
-     --with-binutils=/tools/bin --without-gd --without-cvs \
 
-     --with-headers=/tools/glibc-kernheaders</userinput></screen>
 
- <para>The meaning of the configure options:</para>
 
- <variablelist>
 
- <varlistentry>
 
- <term><parameter>--disable-profile</parameter></term>
 
- <listitem><para>This builds the
 
- libraries without profiling information. Omit this option if you plan to do
 
- profiling on the temporary tools.</para></listitem>
 
- </varlistentry>
 
- <varlistentry>
 
- <term><parameter>--enable-add-ons=nptl</parameter></term>
 
- <listitem><para>This tells Glibc to use the NPTL add-on as its threading 
 
- library.</para></listitem>
 
- </varlistentry>
 
- <varlistentry>
 
- <term><parameter>--with-tls</parameter></term>
 
- <listitem><para>This tells Glibc to include support for TLS (thread-local storage).
 
- This is required for NPTL to work. </para></listitem>
 
- </varlistentry>
 
- <varlistentry>
 
- <term><parameter>--with-binutils=/tools/bin</parameter></term>
 
- <listitem><para>Strictly speaking this switch is not required. But it does ensure 
 
- nothing can go wrong with regard to what Binutils programs get used during the 
 
- Glibc build.</para></listitem>
 
- </varlistentry>
 
- <varlistentry>
 
- <term><parameter>--without-gd</parameter></term>
 
- <listitem><para>This prevents the build of the <command>memusagestat</command>
 
- program, which strangely enough insists on linking against the host's libraries 
 
- (libgd, libpng, libz, and so forth). </para></listitem>
 
- </varlistentry>
 
- <varlistentry>
 
- <term><parameter>--without-cvs</parameter></term>
 
- <listitem><para>This is meant to prevent
 
- the Makefiles from attempting automatic CVS checkouts when using a CVS
 
- snapshot. But it's not actually needed these days. We use it because it
 
- suppresses an annoying but harmless warning about a missing
 
- <command>autoconf</command> program.</para></listitem>
 
- </varlistentry>
 
- <varlistentry>
 
- <term><parameter>--with-headers=/tools/glibc-kernheaders</parameter></term>
 
- <listitem><para>This tells Glibc to compile against the <quote>raw</quote> 
 
- kernel headers, so that it knows exactly what features the kernel has, and can 
 
- optimize itself accordingly.  Not strictly necessary, but nice to have.</para></listitem>
 
- </varlistentry>
 
- </variablelist>
 
- <para>During this stage you might see the following warning:</para>
 
- <blockquote><screen><computeroutput>configure: WARNING:
 
- *** These auxiliary programs are missing or incompatible versions: msgfmt
 
- *** some features will be disabled.
 
- *** Check the INSTALL file for required versions.</computeroutput></screen></blockquote>
 
- <para>The missing or incompatible <command>msgfmt</command> program is
 
- generally harmless, but it's believed it can sometimes cause problems when
 
- running the test suite.</para>
 
- <para>Compile the package:</para>
 
- <screen><userinput>make</userinput></screen>
 
- <para>Compilation is now complete. As mentioned earlier, we don't recommend
 
- running the test suites for the temporary system here in this chapter. If you
 
- still want to run the Glibc test suite anyway, the following command will do
 
- so:</para>
 
- <screen><userinput>make check</userinput></screen>
 
- <para>The Glibc test suite is highly dependent on certain functions of your host
 
- system, in particular the kernel. Additionally, here in this chapter some tests
 
- can be adversely affected by existing tools or environmental issues on the host
 
- system. Of course, these won't be a problem when we run the Glibc test suite
 
- inside the chroot environment of <xref linkend="chapter-building-system"/>. In
 
- general, the Glibc test suite is always expected to pass. However, as mentioned
 
- above, in certain circumstances some failures are unavoidable. Here is a list
 
- of the most common issues we are aware of:</para>
 
- <itemizedlist>
 
- <listitem><para>The <emphasis>math</emphasis> tests sometimes fail when running
 
- on systems where the CPU is not a relatively new genuine Intel or authentic AMD.
 
- Certain optimization settings are also known to be a factor here.</para></listitem>
 
- <listitem><para>The <emphasis>gettext</emphasis> test sometimes fails due to
 
- host system issues. The exact reasons are not yet clear.</para></listitem>
 
- <listitem><para>The <emphasis>atime</emphasis> test sometimes fails when the
 
- LFS partition is mounted with the <parameter>noatime</parameter> option, or due
 
- to other file system quirks.</para></listitem>
 
- <listitem><para>The <emphasis>shm</emphasis> test might fail when the host
 
- system is running the devfs file system but doesn't have the <systemitem class="filesystem">tmpfs</systemitem> file system
 
- mounted at <filename class="directory">/dev/shm</filename> due to lack of support for tmpfs in
 
- the kernel.</para></listitem>
 
- <listitem><para>When running on older and slower hardware, some tests might
 
- fail due to test timeouts being exceeded.</para></listitem>
 
- </itemizedlist>
 
- <para>In summary, don't worry too much if you see Glibc test suite failures
 
- here in this chapter. The Glibc in <xref linkend="chapter-building-system"/> is
 
- the one we'll ultimately end up using, so that is the one we would really like
 
- to see pass the tests (but even there some failures could still occur -- the
 
- <emphasis>math</emphasis> tests, for example). When experiencing a failure,
 
- make a note of it, then continue by reissuing the <command>make
 
- check</command>. The test suite should pick up where it left off and continue.
 
- You can circumvent this stop-start sequence by issuing a <command>make -k
 
- check</command>. But if you do that, be sure to log the output so that you can
 
- later peruse the log file and examine the total number of failures.</para>
 
- <para>Though it is a harmless message, the install stage of Glibc will at the
 
- end complain about the absence of <filename>/tools/etc/ld.so.conf</filename>.
 
- Prevent this confusing little warning with:</para>
 
- <screen><userinput>mkdir /tools/etc
 
- touch /tools/etc/ld.so.conf</userinput></screen>
 
- <para>Now install the package:</para>
 
- <screen><userinput>make install</userinput></screen>
 
- <para>Different countries and cultures have varying conventions for how to
 
- communicate. These conventions range from very simple ones, such as the format
 
- for representing dates and times, to very complex ones, such as the language
 
- spoken. The <quote>internationalization</quote> of GNU programs works by means
 
- of <emphasis>locales</emphasis>.</para>
 
- <note><para>If you are not running the test suites here in this chapter as per
 
- our recommendation, there is little point in installing the locales now. We'll
 
- be installing the locales in the next chapter.</para></note>
 
- <para>If you still want to install the Glibc locales anyway, the following
 
- command will do so:</para>
 
- <screen><userinput>make localedata/install-locales</userinput></screen>
 
- <para>An alternative to running the previous command is to install only those
 
- locales which you need or want. This can be achieved by using the
 
- <command>localedef</command> command. Information on this can be found in
 
- the <filename>INSTALL</filename> file in the Glibc source. However, there are
 
- a number of locales that are essential for the tests of future packages to
 
- pass, in particular, the <emphasis>libstdc++</emphasis> tests from GCC. The
 
- following instructions, instead of the install-locales target above, will
 
- install the minimum set of locales necessary for the tests to run
 
- successfully:</para>
 
- <screen><userinput>mkdir -p /tools/lib/locale
 
- localedef -i de_DE -f ISO-8859-1 de_DE
 
- localedef -i de_DE@euro -f ISO-8859-15 de_DE@euro
 
- localedef -i en_HK -f ISO-8859-1 en_HK
 
- localedef -i en_PH -f ISO-8859-1 en_PH
 
- localedef -i en_US -f ISO-8859-1 en_US
 
- localedef -i es_MX -f ISO-8859-1 es_MX
 
- localedef -i fa_IR -f UTF-8 fa_IR
 
- localedef -i fr_FR -f ISO-8859-1 fr_FR
 
- localedef -i fr_FR@euro -f ISO-8859-15 fr_FR@euro
 
- localedef -i it_IT -f ISO-8859-1 it_IT
 
- localedef -i ja_JP -f EUC-JP ja_JP</userinput></screen>
 
- </sect2>
 
- <sect2 role="content"><title/>
 
- <para>The details on this package are found in <xref linkend="contents-glibc"/>.</para>
 
- </sect2>
 
- </sect1>
 
 
  |