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
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
|
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
<!ENTITY % general-entities SYSTEM "../general.ent">
%general-entities;
]>
<sect1 id="ch-tools-gcc-pass2" role="wrap">
<?dbhtml filename="gcc-pass2.html"?>
<sect1info condition="script">
<productname>gcc-pass2</productname>
<productnumber>&gcc-version;</productnumber>
<address>&gcc-url;</address>
</sect1info>
<title>GCC-&gcc-version; - Pass 2</title>
<indexterm zone="ch-tools-gcc-pass2">
<primary sortas="a-GCC">GCC</primary>
<secondary>tools, pass 2</secondary>
</indexterm>
<sect2 role="package">
<title/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
href="../chapter06/gcc.xml"
xpointer="xpointer(/sect1/sect2[1]/para[1])"/>
<segmentedlist>
<segtitle>&buildtime;</segtitle>
<segtitle>&diskspace;</segtitle>
<seglistitem>
<seg>&gcc-ch5p2-sbu;</seg>
<seg>&gcc-ch5p2-du;</seg>
</seglistitem>
</segmentedlist>
</sect2>
<sect2 role="installation">
<title>Installation of GCC</title>
<para>Our first build of GCC has installed a couple of internal system
headers. Normally one of them, <filename>limits.h</filename>, will in turn
include the corresponding system <filename>limits.h</filename> header, in
this case, <filename>/tools/include/limits.h</filename>. However, at the
time of the first build of gcc <filename>/tools/include/limits.h</filename>
did not exist, so the internal header that GCC installed is a partial,
self-contained file and does not include the extended features of the
system header. This was adequate for building the temporary libc, but this
build of GCC now requires the full internal header. Create a full version
of the internal header using a command that is identical to what the GCC
build system does in normal circumstances:</para>
<screen><userinput remap="pre">cat gcc/limitx.h gcc/glimits.h gcc/limity.h > \
`dirname $($LFS_TGT-gcc -print-libgcc-file-name)`/include-fixed/limits.h</userinput></screen>
<!--
<para>For x86 machines, the limited number of registers is a bottleneck
for the system. Free one up by not using a frame pointer that is not
needed:</para>
<screen><userinput remap="pre">case `uname -m` in
i?86) sed -i 's/^T_CFLAGS =$/& -fomit-frame-pointer/' gcc/Makefile.in ;;
esac</userinput></screen>
-->
<para>Once again, change the location of GCC's default dynamic linker to
use the one installed in <filename
class="directory">/tools</filename>.</para>
<screen><userinput remap="pre">for file in gcc/config/{linux,i386/linux{,64}}.h
do
cp -uv $file{,.orig}
sed -e 's@/lib\(64\)\?\(32\)\?/ld@/tools&@g' \
-e 's@/usr@/tools@g' $file.orig > $file
echo '
#undef STANDARD_STARTFILE_PREFIX_1
#undef STANDARD_STARTFILE_PREFIX_2
#define STANDARD_STARTFILE_PREFIX_1 "/tools/lib/"
#define STANDARD_STARTFILE_PREFIX_2 ""' >> $file
touch $file.orig
done</userinput></screen>
<para>If building on x86_64, change the default directory name for 64-bit
libraries to <quote>lib</quote>:</para>
<screen><userinput remap="pre">case $(uname -m) in
x86_64)
sed -e '/m64=/s/lib64/lib/' \
-i.orig gcc/config/i386/t-linux64
;;
esac</userinput></screen>
<para>As in the first build of GCC it requires the GMP, MPFR and MPC
packages. Unpack the tarballs and move them into the required directory
names:</para>
<screen><userinput remap="pre">tar -xf ../mpfr-&mpfr-version;.tar.xz
mv -v mpfr-&mpfr-version; mpfr
tar -xf ../gmp-&gmp-version;.tar.xz
mv -v gmp-&gmp-version; gmp
tar -xf ../mpc-&mpc-version;.tar.gz
mv -v mpc-&mpc-version; mpc</userinput></screen>
<!--
<para>As in the first build of GCC, fix a problem identified upstream:</para>
<screen><userinput remap="pre">sed -i 's/if \((code.*))\)/if (\1 \&\& \!DEBUG_INSN_P (insn))/' gcc/sched-deps.c</userinput></screen>
-->
<para>Create a separate build directory again:</para>
<screen><userinput remap="pre">mkdir -v build
cd build</userinput></screen>
<para>Before starting to build GCC, remember to unset any environment
variables that override the default optimization flags.</para>
<para>Now prepare GCC for compilation:</para>
<screen><userinput remap="configure">CC=$LFS_TGT-gcc \
CXX=$LFS_TGT-g++ \
AR=$LFS_TGT-ar \
RANLIB=$LFS_TGT-ranlib \
../configure \
--prefix=/tools \
--with-local-prefix=/tools \
--with-native-system-header-dir=/tools/include \
--enable-languages=c,c++ \
--disable-libstdcxx-pch \
--disable-multilib \
--disable-bootstrap \
--disable-libgomp</userinput></screen>
<variablelist>
<title>The meaning of the new configure options:</title>
<varlistentry>
<term><parameter>--enable-languages=c,c++</parameter></term>
<listitem>
<para>This option ensures that both the C and C++ compilers are
built.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>--disable-libstdcxx-pch</parameter></term>
<listitem>
<para>Do not build the pre-compiled header (PCH) for
<filename class="libraryfile">libstdc++</filename>. It takes up a
lot of space, and we have no use for it.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>--disable-bootstrap</parameter></term>
<listitem>
<para>For native builds of GCC, the default is to do a "bootstrap"
build. This does not just compile GCC, but compiles it several times.
It uses the programs compiled in a first round to compile itself a
second time, and then again a third time. The second and third
iterations are compared to make sure it can reproduce itself
flawlessly. This also implies that it was compiled correctly.
However, the LFS build method should provide a solid compiler
without the need to bootstrap each time.</para>
</listitem>
</varlistentry>
</variablelist>
<para>Compile the package:</para>
<screen><userinput remap="make">make</userinput></screen>
<para>Install the package:</para>
<screen><userinput remap="install">make install</userinput></screen>
<para>As a finishing touch, create a symlink. Many programs and scripts
run <command>cc</command> instead of <command>gcc</command>, which is
used to keep programs generic and therefore usable on all kinds of UNIX
systems where the GNU C compiler is not always installed. Running
<command>cc</command> leaves the system administrator free to decide
which C compiler to install:</para>
<screen><userinput remap="install">ln -sv gcc /tools/bin/cc</userinput></screen>
<caution>
<para>At this point, it is imperative to stop and ensure that the basic
functions (compiling and linking) of the new toolchain are working as
expected. To perform a sanity check, run the following commands:</para>
<screen><userinput>echo 'int main(){}' > dummy.c
cc dummy.c
readelf -l a.out | grep ': /tools'</userinput></screen>
<para>If everything is working correctly, there should be no errors,
and the output of the last command will be of the form:</para>
<screen><computeroutput>[Requesting program interpreter: /tools/lib64/ld-linux-x86-64.so.2]</computeroutput></screen>
<para>Note that the dynamic linker will be /tools/lib/ld-linux.so.2
for 32-bit machines.</para>
<para>If the output is not shown as above or there was no output at all,
then something is wrong. Investigate and retrace the steps to find out
where the problem is and correct it. This issue must be resolved before
continuing on. First, perform the sanity check again, using
<command>gcc</command> instead of <command>cc</command>. If this works,
then the <filename class="symlink">/tools/bin/cc</filename> symlink is
missing. Install the symlink as per above.
Next, ensure that the <envar>PATH</envar> is correct. This
can be checked by running <command>echo $PATH</command> and verifying that
<filename class="directory">/tools/bin</filename> is at the head of the
list. If the <envar>PATH</envar> is wrong it could mean that you are not
logged in as user <systemitem class="username">lfs</systemitem> or that
something went wrong back in <xref linkend="ch-tools-settingenviron"
role="."/></para>
<para>Once all is well, clean up the test files:</para>
<screen><userinput>rm -v dummy.c a.out</userinput></screen>
</caution>
</sect2>
<sect2 role="content">
<title/>
<para>Details on this package are located in
<xref linkend="contents-gcc" role="."/></para>
</sect2>
</sect1>
|
