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
|
<?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-gcc-pass1" role="wrap">
<title>GCC-&gcc-version; - Pass 1</title>
<?dbhtml filename="gcc-pass1.html"?>
<indexterm zone="ch-tools-gcc-pass1">
<primary sortas="a-GCC">GCC</primary>
<secondary>tools, pass 1</secondary></indexterm>
<sect2 role="package"><title/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/gcc.xml" xpointer="xpointer(/sect1/sect2[1]/para[1])"/>
<segmentedlist>
<segtitle>&buildtime;</segtitle>
<segtitle>&diskspace;</segtitle>
<seglistitem><seg>4.4 SBU</seg><seg>300 MB</seg></seglistitem>
</segmentedlist>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/gcc.xml" xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
</sect2>
<sect2 role="installation">
<title>Installation of GCC</title>
<para>Unpack only the GCC-core tarball, as we won't be needing the C++ compiler
nor the test suite here.</para>
<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 GCC.</para>
<para>The GCC documentation recommends building GCC outside of the source
directory in a dedicated build directory:</para>
<screen><userinput>mkdir ../gcc-build
cd ../gcc-build</userinput></screen>
<para>Prepare GCC for compilation:</para>
<screen><userinput>CC="gcc -B/usr/bin" ../gcc-&gcc-version;/configure \
--prefix=/tools --libexecdir=/tools/lib \
--with-local-prefix=/tools --disable-nls \
--enable-shared --enable-languages=c</userinput></screen>
<para>The meaning of the configure options:</para>
<variablelist>
<varlistentry>
<term><parameter>CC="gcc -B/usr/bin"</parameter></term>
<listitem><para>This parameter fixes a possible problem with building GCC
at this stage, first noticed in LFS 5.1.1. If our host uses a new version
of Binutils than we compiled, the host compiler may try use features not
supported by our new linker, causing compilation errors. By passing the -B
flag to gcc, we cause the compiler to temporarily use the host's linker,
which solves the problem.</para></listitem>
</varlistentry>
<varlistentry>
<term><parameter>--with-local-prefix=/tools</parameter></term>
<listitem><para>The purpose of this switch is to remove <filename class="directory">/usr/local/include</filename>
from <command>gcc</command>'s include search path. This is not absolutely
essential; however, we want to try to minimize the influence of the host
system, so this a sensible thing to do.</para></listitem>
</varlistentry>
<varlistentry>
<term><parameter>--enable-shared</parameter></term>
<listitem><para>This switch may
seem counter-intuitive at first. But using it allows the building of
<filename>libgcc_s.so.1</filename> and <filename>libgcc_eh.a</filename>, and
having <filename>libgcc_eh.a</filename> available ensures that the configure
script for Glibc (the next package we compile) produces the proper results.
Note that the GCC binaries will still be linked
statically, as this is controlled by the <parameter>-static</parameter>
value of BOOT_LDFLAGS in the next step.</para></listitem>
</varlistentry>
<varlistentry>
<term><parameter>--enable-languages=c</parameter></term>
<listitem><para>This option
ensures that only the C compiler is built. The option is only needed when you
have downloaded and unpacked the full GCC tarball.</para></listitem>
</varlistentry>
</variablelist>
<para>Continue with compiling the package:</para>
<screen><userinput>make BOOT_LDFLAGS="-static" bootstrap</userinput></screen>
<para>The meaning of the make parameters:</para>
<variablelist>
<varlistentry>
<term><parameter>BOOT_LDFLAGS="-static"</parameter></term>
<listitem><para>This tells GCC to link its programs statically.</para></listitem>
</varlistentry>
<varlistentry>
<term><parameter>bootstrap</parameter></term>
<listitem><para>This target doesn't 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.
It then compares these second and third compiles to make sure it can
reproduce itself flawlessly, which most probably means that it was
compiled correctly.</para></listitem>
</varlistentry>
</variablelist>
<para>Compilation is now complete, and at this point we would normally run the
test suite. But, as mentioned before, the test suite framework is not in place
yet. And there would be little point in running the tests anyhow, since the
programs from this first pass will soon be replaced.</para>
<para>Now install the package:</para>
<screen><userinput>make install</userinput></screen>
<para>As a finishing touch we'll create a symlink. Many programs and scripts
run <command>cc</command> instead of <command>gcc</command>,
a thing meant to keep programs generic and therefore usable on all kinds of
Unix systems. Not everybody has the GNU C compiler installed. Simply running
<command>cc</command> leaves the system administrator free to decide what
C compiler to install, as long as there's a symlink pointing to it:</para>
<screen><userinput>ln -s gcc /tools/bin/cc</userinput></screen>
</sect2>
<sect2 role="content"><title/>
<para>The details on this package are found in <xref linkend="contents-gcc"/>.</para>
</sect2>
</sect1>
|
