123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165 |
- <sect2><title> </title><para> </para></sect2>
- <sect2>
- <title>Glibc installation</title>
- <para>Before starting to install Glibc, you must <userinput>cd</userinput>
- into the <filename>glibc-&glibc-version;</filename> directory and unpack
- Glibc-linuxthreads in that directory, not in the directory where you usually
- unpack all the sources.</para>
- <note><para>We are going to run the test suite for Glibc in this chapter.
- However, it's worth pointing out that the Glibc test suite we run in this
- section is considered not as important as the one we run in Chapter 6.</para></note>
- <para>This package is known to behave badly when you have changed its
- default optimization flags (including the -march and -mcpu options).
- Therefore, if you have defined any environment variables that override
- default optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting
- 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>Though it is a harmless message, the install stage of Glibc will
- complain about the absence of <filename>/tools/etc/ld.so.conf</filename>.
- Fix this annoying little error with:</para>
- <para><screen><userinput>mkdir /tools/etc
- touch /tools/etc/ld.so.conf</userinput></screen></para>
- <para>Also, Glibc has a subtle problem when compiled with GCC 3.3.1.
- Apply the following patch to fix this:</para>
- <para><screen><userinput>patch -Np1 -i ../&glibc-sscanf-patch;</userinput></screen></para>
- <para>The Glibc documentation recommends building Glibc outside of the source
- directory in a dedicated build directory:</para>
- <para><screen><userinput>mkdir ../glibc-build
- cd ../glibc-build</userinput></screen></para>
- <para>Next, prepare Glibc to be compiled:</para>
- <para><screen><userinput>../glibc-&glibc-version;/configure --prefix=/tools \
- --disable-profile --enable-add-ons \
- --with-headers=/tools/include \
- --with-binutils=/tools/bin \
- --without-gd</userinput></screen></para>
- <para>The meaning of the configure options:</para>
- <itemizedlist>
- <listitem><para><userinput>--disable-profile</userinput>: This disables the
- building of the libraries with profiling information. Omit this option if you
- plan to do profiling.</para></listitem>
- <listitem><para><userinput>--enable-add-ons</userinput>: This enables any
- add-ons that were installed with Glibc, in our case Linuxthreads.</para></listitem>
- <listitem><para><userinput>--with-binutils=/tools/bin</userinput> and
- <userinput>--with-headers=/tools/include</userinput>: Strictly speaking
- these switches are not required. But they ensure nothing can go wrong with
- regard to what kernel headers and Binutils programs get used during the
- Glibc build.</para></listitem>
- <listitem><para><userinput> --without-gd</userinput>: This switch ensures
- that we don't build the <userinput>memusagestat</userinput> program, which
- strangely enough insists on linking against the host's libraries (libgd,
- libpng, libz, and so forth).</para></listitem>
- </itemizedlist>
- <para>During this stage you might see the following warning:</para>
- <blockquote><screen>configure: WARNING:
- *** These auxiliary programs are missing or incompatible versions: msgfmt
- *** some features will be disabled.
- *** Check the INSTALL file for required versions.</screen></blockquote>
- <para>The missing or incompatible <filename>msgfmt</filename> program is
- generally harmless, but it's believed it can sometimes cause problems when
- running the test suite.</para>
- <para>Compile the package:</para>
- <para><screen><userinput>make</userinput></screen></para>
- <para>Run the test suite:</para>
- <para><screen><userinput>make check</userinput></screen></para>
- <para>The Glibc test suite is highly dependent on certain functions of your host
- system, in particular the kernel. Additionally, here in Chapter 5, 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 Chapter 6. In general, the Glibc test suite is
- always expected to pass. However, as mentioned above, some failures are
- unavoidable in certain circumstances. Here is a list of the most common issues
- we are aware of:</para>
- <itemizedlist>
- <listitem><para>The math tests sometimes fail when running on systems where the
- CPU is not a relatively new genuine Intel or genuine AMD. Certain optimization
- settings are also known to be a factor here.</para></listitem>
- <listitem><para>The gettext test sometimes fails due to host system issues. The
- exact reasons are not yet clear.</para></listitem>
- <listitem><para>The atime test sometimes fails when the LFS partition is mounted
- with the noatime option or due to other file system quirks.</para></listitem>
- <listitem><para>In general, when running on slower hardware, some tests might
- fail due to test timeouts being exceeded.</para></listitem>
- <listitem><para>The shm test might fail in the circumstances of the host system
- running the devfs file system but not having the tmpfs file system mounted at
- /dev/shm due to lack of support for tmpfs in the kernel.</para></listitem>
- </itemizedlist>
- <para>In summary, don't worry too much if you see Glibc test suite failures here
- in Chapter 5. The Glibc in Chapter 6 is the one we'll ultimately end up using so
- that is the one we would really like to see pass. But please keep in mind, even
- in Chapter 6 some failures could still occur, the math tests for example. When
- experiencing a failure, note the failure then continue on by reissuing the
- <userinput>make check</userinput>. The test suite should pick up where it left
- off and continue on. You can circumvent this stop-start sequence by issuing a
- <userinput>make -k check</userinput>. But If you do that, be sure to log the
- output so that you can later on peruse the log file and examine the total number
- of failures.</para>
- <para>Now install the package:</para>
- <para><screen><userinput>make install</userinput></screen></para>
- <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. This "internationalization" works by means of locales. We'll install the
- Glibc locales now:</para>
- <para><screen><userinput>make localedata/install-locales</userinput></screen></para>
- <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
- <userinput>localedef</userinput> command. Information on this can be
- found in the <filename>INSTALL</filename> file in the
- <filename>glibc-&glibc-version;</filename> source. However, there are a
- number of locales that are essential for the tests of future packages
- to pass correctly, in particular, the libstdc++ tests from GCC. The following
- instructions, instead of the install-locales command above, will install
- the minimum set of locales necessary for the tests to run successfully:</para>
- <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 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></para>
- </sect2>
|