| 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 unpackGlibc-linuxthreads in that directory, not in the directory where you usuallyunpack 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 thissection 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 itsdefault optimization flags (including the -march and -mcpu options).Therefore, if you have defined any environment variables that overridedefault optimizations, such as CFLAGS and CXXFLAGS, we recommend unsettingthem when building Glibc.</para><para>Basically, compiling Glibc in any other way than the book suggestsis putting the stability of your system at risk.</para><para>Though it is a harmless message, the install stage of Glibc willcomplain about the absence of <filename>/tools/etc/ld.so.conf</filename>.Fix this annoying little error with:</para><para><screen><userinput>mkdir /tools/etctouch /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 sourcedirectory in a dedicated build directory:</para><para><screen><userinput>mkdir ../glibc-buildcd ../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 thebuilding of the libraries with profiling information. Omit this option if youplan to do profiling.</para></listitem><listitem><para><userinput>--enable-add-ons</userinput>: This enables anyadd-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 speakingthese switches are not required. But they ensure nothing can go wrong withregard to what kernel headers and Binutils programs get used during theGlibc build.</para></listitem><listitem><para><userinput> --without-gd</userinput>: This switch ensuresthat we don't build the <userinput>memusagestat</userinput> program, whichstrangely 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 isgenerally harmless, but it's believed it can sometimes cause problems whenrunning 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 hostsystem, in particular the kernel. Additionally, here in Chapter 5, some testscan be adversely affected by existing tools or environmental issues on the hostsystem. Of course, these won't be a problem when we run the Glibc test suiteinside the chroot environment of Chapter 6. In general, the Glibc test suite isalways expected to pass. However, as mentioned above, some failures areunavoidable in certain circumstances. Here is a list of the most common issueswe 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 optimizationsettings are also known to be a factor here.</para></listitem><listitem><para>The gettext test sometimes fails due to host system issues. Theexact reasons are not yet clear.</para></listitem><listitem><para>The atime test sometimes fails when the LFS partition is mountedwith the noatime option or due to other file system quirks.</para></listitem><listitem><para>In general, when running on slower hardware, some tests mightfail due to test timeouts being exceeded.</para></listitem><listitem><para>The shm test might fail in the circumstances of the host systemrunning 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 herein Chapter 5. The Glibc in Chapter 6 is the one we'll ultimately end up using sothat is the one we would really like to see pass. But please keep in mind, evenin Chapter 6 some failures could still occur, the math tests for example. Whenexperiencing a failure, note the failure then continue on by reissuing the<userinput>make check</userinput>. The test suite should pick up where it leftoff 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 theoutput so that you can later on peruse the log file and examine the total numberof 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 tocommunicate. These conventions range from very simple ones, such as the formatfor representing dates and times, to very complex ones, such as the languagespoken. This "internationalization" works by means of locales. We'll install theGlibc locales now:</para><para><screen><userinput>make localedata/install-locales</userinput></screen></para><para>An alternative to running the previous command is to install onlythose locales which you need or want. This can be achieved by using the<userinput>localedef</userinput> command. Information on this can befound in the <filename>INSTALL</filename> file in the<filename>glibc-&glibc-version;</filename> source. However, there are anumber of locales that are essential for the tests of future packagesto 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/localelocaledef -i de_DE -f ISO-8859-1 de_DElocaledef -i de_DE@euro -f ISO-8859-15 de_DE@eurolocaledef -i en_HK -f ISO-8859-1 en_HKlocaledef -i en_PH -f ISO-8859-1 en_PHlocaledef -i en_US -f ISO-8859-1 en_USlocaledef -i es_MX -f ISO-8859-1 es_MXlocaledef -i fr_FR -f ISO-8859-1 fr_FRlocaledef -i fr_FR@euro -f ISO-8859-15 fr_FR@eurolocaledef -i it_IT -f ISO-8859-1 it_ITlocaledef -i ja_JP -f EUC-JP ja_JP</userinput></screen></para></sect2>
 |