Subversion Repositories svn LFS-FR


Go to most recent revision | Blame | Compare with Previous | Last modification | View Log | RSS feed

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
 "" [
 <!ENTITY % general-entities SYSTEM "../general.ent">

<sect1 id="ch-final-preps-settingenviron">
  <?dbhtml filename="settingenvironment.html"?>

  <title>Setting Up the Environment</title>

  <para os="a">Set up a good working environment by creating two new startup
  files for the <command>bash</command> shell. While logged in as user
  <systemitem class="username">clfs</systemitem>, issue the following
  command to create a new <filename>.bash_profile</filename>:</para>

<screen os="b"><userinput>cat &gt; ~/.bash_profile &lt;&lt; "EOF"
<literal>exec env -i HOME=${HOME} TERM=${TERM} PS1='\u:\w\$ ' /bin/bash</literal>

  <para os="c">When logged on as user <systemitem class="username">clfs</systemitem>,
  the initial shell is usually a <emphasis>login</emphasis> shell which
  reads the <filename>/etc/profile</filename> of the host (probably
  containing some settings and environment variables) and then
  <filename>.bash_profile</filename>. The
  <command>exec env -i.../bin/bash</command> command in the
  <filename>.bash_profile</filename> file replaces the running shell with
  a new one with a completely empty environment, except for the
  <envar>HOME</envar>, <envar>TERM</envar>, and <envar>PS1</envar> variables.
  This ensures that no unwanted and potentially hazardous environment
  variables from the host system leak into the build environment. The
  technique used here achieves the goal of ensuring a clean environment.</para>

  <para os="d">The new instance of the shell is a <emphasis>non-login</emphasis>
  shell, which does not read the <filename>/etc/profile</filename> or
  <filename>.bash_profile</filename> files, but rather reads the
  <filename>.bashrc</filename> file instead. Create the
  <filename>.bashrc</filename> file now:</para>

<screen os="e"><userinput>cat &gt; ~/.bashrc &lt;&lt; "EOF"
<literal>set +h
umask 022
export CLFS LC_ALL PATH</literal>

  <para os="f">The <command>set +h</command> command turns off
  <command>bash</command>'s hash function. Hashing is ordinarily a useful
  feature&mdash;<command>bash</command> uses a hash table to remember the
  full path of executable files to avoid searching the <envar>PATH</envar>
  time and again to find the same executable. However, the new tools should
  be used as soon as they are installed. By switching off the hash function,
  the shell will always search the <envar>PATH</envar> when a program is to
  be run. As such, the shell will find the newly compiled tools in
  <filename class="directory">${CLFS}/cross-tools</filename> as soon as they are
  available without remembering a previous version of the same program in a
  different location.</para>

  <para os="g">Setting the user file-creation mask (umask) to 022 ensures that
  newly created files and directories are only writable by their owner,
  but are readable and executable by anyone (assuming default modes are
  used by the open(2) system call, new files will end up with permission
  mode 644 and directories with mode 755).</para>

  <para os="h">The <envar>CLFS</envar> variable should be set to the
  chosen mount point.</para>

  <para os="i">The <envar>LC_ALL</envar> variable controls the localization of
  certain programs, making their messages follow the conventions of a
  specified country.  If the host system uses a version of EGLIBC older
  than 2.2.4, having <envar>LC_ALL</envar> set to something other than
  <quote>POSIX</quote> or <quote>C</quote> (during this chapter) may cause
  issues if you exit the chroot environment and wish to return later.
  Setting <envar>LC_ALL</envar> to <quote>POSIX</quote> or <quote>C</quote>
  (the two are equivalent) ensures that everything will work as expected in
  the chroot environment.</para>

  <para os="j">By putting <filename class="directory">${CLFS}/cross-tools/bin</filename>
  at the beginning of the <envar>PATH</envar>, the cross-compiler
  built in <xref linkend="chapter-cross-tools"/> will be picked up by
  the build process for the temp-system packages before anything that
  may be installed on the host. This, combined with turning off
  hashing, helps to ensure that you will be using the cross-compile
  tools to build the temp-system in /tools.</para>

  <para os="k">Finally, to have the environment fully prepared for building the
  temporary tools, source the just-created user profile:</para>

<screen os="l"><userinput>source ~/.bash_profile</userinput></screen>