| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124 | 
							- <sect1 id="ch-tools-binutils-pass1">
 
- <title>Installing Binutils-&binutils-version; - Pass 1</title>
 
- <?dbhtml filename="binutils-pass1.html" dir="chapter05"?>
 
- <screen>&buildtime; &binutils-time-tools-pass1;
 
- &diskspace; &binutils-compsize-tools-pass1;</screen>
 
- &aa-binutils-down;
 
- &aa-binutils-dep;
 
- <sect2><title> </title><para> </para></sect2>
 
- <sect2>
 
- <title>Installation of Binutils</title>
 
- <para>It is important that Binutils be the first package to get compiled,
 
- because both Glibc and GCC perform various tests on the available linker and
 
- assembler to determine which of their own features to enable.</para>
 
- <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 or
 
- modifying them when building Binutils.</para>
 
- <para>The Binutils documentation recommends building Binutils outside of the
 
- source directory in a dedicated build directory:</para>
 
- <screen><userinput>mkdir ../binutils-build
 
- cd ../binutils-build</userinput></screen>
 
- <note><para>If you want the SBU values listed in the rest of the book to be of
 
- any use, you will have to measure the time it takes to build this package. To
 
- achieve this easily, you could do something like:
 
- <userinput>time { ./configure ... && ... && ... && make install; }</userinput>.</para></note>
 
- <para>Now prepare Binutils for compilation:</para>
 
- <screen><userinput>../&binutils-dir;/configure --prefix=/tools --disable-nls</userinput></screen>
 
- <para>The meaning of the configure options:</para>
 
- <itemizedlist>
 
- <listitem><para><userinput>--prefix=/tools</userinput>: This tells the
 
- configure script to prepare to install the Binutils programs in the
 
- <filename>/tools</filename> directory.</para></listitem>
 
- <listitem><para><userinput>--disable-nls</userinput>: This disables
 
- internationalization (a word often shortened to i18n). We don't need this
 
- for our static programs and <emphasis>nls</emphasis> often causes problems
 
- when linking statically.</para></listitem>
 
- </itemizedlist>
 
- <para>Continue with compiling the package:</para>
 
- <screen><userinput>make configure-host
 
- make LDFLAGS="-all-static"</userinput></screen>
 
- <para>The meaning of the make parameters:</para>
 
- <itemizedlist>
 
- <listitem><para><userinput>configure-host</userinput>: This forces all the
 
- subdirectories to be configured immediately. A statically linked build will
 
- fail without it. We therefore use this option to work around the
 
- problem.</para></listitem>
 
- <listitem><para><userinput>LDFLAGS="-all-static"</userinput>: This tells the
 
- linker that all the Binutils programs should be linked statically. However,
 
- strictly speaking, <emphasis>"-all-static"</emphasis> is first passed to the
 
- <command>libtool</command> program which then passes
 
- <emphasis>"-static"</emphasis> on to the linker.</para></listitem>
 
- </itemizedlist>
 
- <para>Compilation is now complete. This is the point where we would normally
 
- run the test suite. But as discussed earlier, we don't recommend running the
 
- test suites for the temporary tools here in this chapter. However, even if we
 
- still wanted to run the Binutils test suite, we're unable do so at this early
 
- stage because the test suite framework is not yet in place. Not only that, the
 
- programs from this first pass will soon be overwritten by those installed in
 
- the second pass.</para>
 
- <para>And install the package:</para>
 
- <screen><userinput>make install</userinput></screen>
 
- <para>Now prepare the linker for the "locking in" of Glibc later on:</para>
 
- <screen><userinput>make -C ld clean
 
- make -C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib</userinput></screen>
 
- <para>The meaning of the make parameters:</para>
 
- <itemizedlist>
 
- <listitem><para><userinput>-C ld clean</userinput>: This tells the make program
 
- to remove all the compiled files, but only in the <filename>ld</filename>
 
- subdirectory.</para></listitem>
 
- <listitem><para><userinput>-C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib</userinput>:
 
- This option rebuilds everything in the <filename>ld</filename> subdirectory.
 
- Specifying the LIB_PATH makefile variable on the command line allows us to
 
- override the default value and have it point to our temporary tools location.
 
- The value of this variable specifies the linker's default library search path.
 
- You'll see how this preparation is used later on in the
 
- chapter.</para></listitem>
 
- </itemizedlist>
 
- <!-- HACK - Force some whitespace to appease tidy -->
 
- <literallayout></literallayout>
 
- <warning><para>Do not yet remove the Binutils build and source directories. You
 
- will need them again in their current state a bit further on in this
 
- chapter.</para></warning>
 
- <!-- HACK - Force some whitespace to appease tidy -->
 
- <literallayout></literallayout>
 
- </sect2>
 
- <sect2><title> </title><para> </para>
 
- <para>The details on this package are found in <xref linkend="contents-binutils"/>.</para>
 
- <para> </para></sect2>
 
- </sect1>
 
 
  |