1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
|
<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 <filename>$LFS/tools/src</filename>
as you would normally do.</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-&glibc-sscanf-patch-version;.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>
|
