source: chapter05/glibc.xml@ 0ebda11

<?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-glibc" role="wrap">
  <?dbhtml filename="glibc.html"?>

  <sect1info condition="script">
    <productname>glibc</productname>
    <productnumber>&glibc-version;</productnumber>
    <address>&glibc-url;</address>
  </sect1info>

  <title>Glibc-&glibc-version;</title>

  <indexterm zone="ch-tools-glibc">
    <primary sortas="a-Glibc">Glibc</primary>
    <secondary>tools</secondary>
  </indexterm>

  <sect2 role="package">
    <title/>

    <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
    href="../chapter08/glibc.xml"
    xpointer="xpointer(/sect1/sect2[1]/para[1])"/>

    <segmentedlist>
      <segtitle>&buildtime;</segtitle>
      <segtitle>&diskspace;</segtitle>

      <seglistitem>
        <seg>&glibc-tmp-sbu;</seg>
        <seg>&glibc-tmp-du;</seg>
      </seglistitem>
    </segmentedlist>

  </sect2>

  <sect2 role="installation">
    <title>Installation of Glibc</title>

    <para>First, create a symbolic link for LSB compliance. Additionally,
    for x86_64, create a compatibility symbolic link required for proper
    operation of the dynamic library loader:</para>

<screen arch="default"><userinput remap="pre">case $(uname -m) in
    i?86)   ln -sfv ld-linux.so.2 $LFS/lib/ld-lsb.so.3
    ;;
    x86_64) ln -sfv ../lib/ld-linux-x86-64.so.2 $LFS/lib64
            ln -sfv ../lib/ld-linux-x86-64.so.2 $LFS/lib64/ld-lsb-x86-64.so.3
    ;;
esac</userinput></screen>
<!-- no ld-linux.so.2 here as multilib is based on x86_64, not on i686 -->
<screen arch="ml_32,ml_x32,ml_all"><userinput remap="pre">ln -sfv ../lib/ld-linux-x86-64.so.2 $LFS/lib64
ln -sfv ../lib/ld-linux-x86-64.so.2 $LFS/lib64/ld-lsb-x86-64.so.3</userinput></screen>

    <para>Some of the Glibc programs use the non-FHS compliant
    <filename class="directory">/var/db</filename> directory to store their
    runtime data. Apply the following patch to make such programs store their
    runtime data in the FHS-compliant locations:</para>

<screen><userinput remap="pre">patch -Np1 -i ../glibc-&glibc-version;-fhs-1.patch</userinput></screen>

    <para>Fix a build issue with gcc-11.1:</para>

<screen><userinput remap="pre">sed 's/amx_/amx-/' -i sysdeps/x86/tst-cpu-features-supports.c</userinput></screen>

    <para>The Glibc documentation recommends building Glibc 
    in a dedicated build directory:</para>

<screen><userinput remap="pre">mkdir -v build
cd       build</userinput></screen>

    <para>Next, prepare Glibc for compilation:</para>

<screen arch="default"><userinput remap="configure">../configure                             \
      --prefix=/usr                      \
      --host=$LFS_TGT                    \
      --build=$(../scripts/config.guess) \
      --enable-kernel=&min-kernel;                \
      --with-headers=$LFS/usr/include    \
      libc_cv_slibdir=/usr/lib           \
      libc_cv_rtlddir=/usr/lib</userinput></screen>
<screen arch="ml_32,ml_x32,ml_all"><userinput remap="configure">../configure                             \
      --prefix=/usr                      \
      --host=$LFS_TGT                    \
      --build=$(../scripts/config.guess) \
      --enable-kernel=&min-kernel;                \
      --with-headers=$LFS/usr/include    \
      --enable-multi-arch                \
      libc_cv_slibdir=/usr/lib           \
      libc_cv_rtlddir=/usr/lib</userinput></screen>

    <variablelist>
      <title>The meaning of the configure options:</title>

      <varlistentry>
        <term><parameter>--host=$LFS_TGT, --build=$(../scripts/config.guess)</parameter></term>
        <listitem>
          <para>The combined effect of these switches is that Glibc's build system
          configures itself to be cross-compiled, using the cross-linker and
          cross-compiler in <filename class="directory">$LFS/tools</filename>.</para>
        </listitem>
      </varlistentry>

      <varlistentry>
        <term><parameter>--enable-kernel=&min-kernel;</parameter></term>
        <listitem>
          <para>This tells Glibc to compile the library with support
          for &min-kernel; and later Linux kernels.  Workarounds for older
          kernels are not enabled.</para>
        </listitem>
      </varlistentry>

      <varlistentry>
        <term><parameter>--with-headers=$LFS/usr/include</parameter></term>
        <listitem>
          <para>This tells Glibc to compile itself against the headers
          recently installed to the $LFS/usr/include directory, so that
          it knows exactly what features the kernel has and can optimize
          itself accordingly.</para>
        </listitem>
      </varlistentry>

      <varlistentry>
        <term><parameter>libc_cv_slibdir=/usr/lib</parameter></term>
        <listitem>
          <para>This ensures that the library is installed in /usr/lib instead
          of the default /lib64 on 64 bit machines.</para>
        </listitem>
      </varlistentry>

      <varlistentry>
        <term><parameter>libc_cv_rtlddir=/usr/lib</parameter></term>
        <listitem>
          <para>Fix hardcoded path to the executable loader in the
            <command>ldd</command> script.</para>
        </listitem>
      </varlistentry>

      <varlistentry>
        <term><option>libc_cv_include_x86_isa_level=no</option></term>
        <listitem>
          <para>This disables <quote>x86 ISA needed</quote> property in
          Glibc libraries.  Use it <emphasis role="bold">if</emphasis>
          you are building Glibc with <option>-march</option> option in
          <envar>CFLAGS</envar>, to workaround an issue in Glibc-2.33
          breaking it.</para>
        </listitem>
      </varlistentry>

    </variablelist>

    <para>During this stage the following warning might appear:</para>

    <blockquote>
<screen><computeroutput>configure: WARNING:
*** These auxiliary programs are missing or
*** incompatible versions: msgfmt
*** some features will be disabled.
*** Check the INSTALL file for required versions.</computeroutput></screen>
    </blockquote>

    <para>The missing or incompatible <command>msgfmt</command> program is
    generally harmless. This <command>msgfmt</command> program is part of the
    Gettext package which the host distribution should provide.</para>

    <note><para>There have been reports that this package may fail when 
    building as a "parallel make".  If this occurs, rerun the make command
    with a "-j1" option.</para></note>

    <para>Compile the package:</para>

<screen><userinput remap="make">make</userinput></screen>

    <para>Install the package:</para>

    <warning><para>If <envar>LFS</envar> is not properly set, and despite the
    recommendations, you are building as
    <systemitem class="username">root</systemitem>, the next command will
    install the newly built glibc to your host system, which most likely
    will render it unusable. So double check that the environment is
    correctly set, before running the following command.</para></warning>

<screen><userinput remap="install">make DESTDIR=$LFS install</userinput></screen>

    <variablelist>
      <title>The meaning of the <command>make install</command> option:</title>

      <varlistentry>
        <term><parameter>DESTDIR=$LFS</parameter></term>
        <listitem>
          <para>The <envar>DESTDIR</envar> make variable is used by almost all
          packages to define the location where the package should be
          installed. If it is not set, it defaults to the root (<filename
          class="directory">/</filename>) directory. Here we specify that
          the package be installed in <filename class="directory">$LFS
          </filename>, which will become the root after <xref linkend=
          "ch-tools-chroot"/>.</para>
        </listitem>
      </varlistentry>

    </variablelist>

    <!--
      The /usr which gets removed from the RTLDLIST by the sed
      below is set by the libc_cv_rtlddir=/usr/lib above. When
      changing the libc_cv_rtlddir to /lib, the content of the
      ldd script does not need to be patched, but some other
      symlinks created by glibc itself will be not that correct
      and needs to be fixed by other symlinks.

      First setting /usr and than removing /usr seems strange,
      but it looks like that libc_cv_rtlddir has more effect than
      only the pathes in ldd (it has influence on which symlinks
      to the loader are created where) and makes the handling
      in a multilib environment much easier.
      To me, it feels better to go the way with adding/removing
      /usr than to introduce a symlink hell.
      
      Another option to get ldd working properly is to set a
      symlink as "ln -svf lib /usr/lib64" but it has been reported
      that we used that already years ago but dropped it since
      libtool will complain sometimes with "library has been moved"
      warnings.
      Don't know if this is still the case - if not, this one
      symlink seems to be the cleanest way and the sed on ldd will
      be obsolete.
    -->
    <para>Fix hardcoded path to the executable loader in
    <command>ldd</command> script:</para>

<screen><userinput remap="install">sed '/RTLDLIST=/s@/usr@@g' -i $LFS/usr/bin/ldd</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(){}' &gt; dummy.c
$LFS_TGT-gcc dummy.c
readelf -l a.out | grep '/ld-linux'</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: /lib64/ld-linux-x86-64.so.2]</computeroutput></screen>

      <para arch="default">Note that for 32-bit machines, the interpreter name will be
      <filename>/lib/ld-linux.so.2</filename>.</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.</para>

      <para>Once all is well, clean up the test files:</para>

<screen><userinput>rm -v dummy.c a.out</userinput></screen>

    </caution>

    <note><para>Building packages in the next chapter will serve as an
    additional check that the toolchain has been built properly. If some
    package, especially binutils-pass2 or gcc-pass2, fails to build, it is
    an indication that something has gone wrong with the
    previous Binutils, GCC, or Glibc installations.</para></note>

    <para>Now that our cross-toolchain is complete, finalize the installation
    of the limits.h header. For doing so, run a utility provided by the GCC
    developers:</para>

<screen><userinput>$LFS/tools/libexec/gcc/$LFS_TGT/&gcc-version;/install-tools/mkheaders</userinput></screen>

  </sect2>

  <!-- - - - - - - - - - -->
  <!-- Multilib - 32bit  -->
  <!-- - - - - - - - - - -->
  <sect2 arch="ml_32,ml_all">
    <title>Building Glibc - 32bit</title>

    <para>Now recompile for m32. The extracted source can be
    reused but needs to be cleaned before installing the m32
    version of Glibc.</para>

    <para>Clear the build directory and remove artefacts from
    previous build:</para>
      
<screen><userinput remap="pre">make clean
find .. -name "*.a" -delete</userinput></screen>

    <para>Configure Glibc for m32 with the following commands:</para>

<screen><userinput remap="configure">CC="$LFS_TGT-gcc -m32" \
CXX="$LFS_TGT-g++ -m32" \
../configure                             \
      --prefix=/usr                      \
      --host=$LFS_TGT32                  \
      --build=$(../scripts/config.guess) \
      --enable-kernel=&min-kernel;                \
      --with-headers=$LFS/usr/include    \
      --enable-multi-arch                \
      --libdir=/usr/lib32                \
      --libexecdir=/usr/lib32            \
      libc_cv_slibdir=/usr/lib32           \
      libc_cv_rtlddir=/usr/lib32</userinput></screen>

    <para>Compile the package:</para>

<screen><userinput remap="make">make</userinput></screen>

    <para>Install the package:</para>

<screen><userinput remap="install">make DESTDIR=$PWD/DESTDIR install
cp -a DESTDIR/usr/lib32 $LFS/usr/
install -vm644 DESTDIR/usr/include/gnu/{lib-names,stubs}-32.h \
               $LFS/usr/include/gnu/
ln -svf ../lib32/ld-linux.so.2 $LFS/lib/ld-linux.so.2</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(){}' &gt; dummy.c
$LFS_TGT-gcc -m32 dummy.c
readelf -l a.out | grep '/ld-linux'</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: /lib/ld-linux.so.2]</computeroutput></screen>

      <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.</para>

      <para>Once all is well, clean up the test files:</para>

<screen><userinput>rm -v dummy.c a.out</userinput></screen>

    </caution>

  </sect2><!-- m32 -->

  <!-- - - - - - - - - - -->
  <!-- Multilib - x32bit -->
  <!-- - - - - - - - - - -->
  
  <sect2 arch="ml_x32,ml_all">
    <title>Building Glibc - x32bit</title>

    <para>Now recompile for mx32. The extracted source can be
    reused but needs to be cleaned before installing the mx32
    version of Glibc.</para>

    <para>Clear the build directory and remove artefacts from
    previous build:</para>
      
<screen><userinput remap="pre">make clean
find .. -name "*.a" -delete</userinput></screen>

    <para>Configure Glibc for mx32 with the following commands:</para>

<screen><userinput remap="configure">CC="$LFS_TGT-gcc -mx32" \
CXX="$LFS_TGT-g++ -mx32" \
../configure                             \
      --prefix=/usr                      \
      --host=$LFS_TGTX32                 \
      --build=$(../scripts/config.guess) \
      --enable-kernel=&min-kernel;                \
      --with-headers=$LFS/usr/include    \
      --enable-multi-arch                \
      --libdir=/usr/libx32               \
      --libexecdir=/usr/libx32           \
      libc_cv_slibdir=/usr/libx32           \
      libc_cv_rtlddir=/usr/libx32</userinput></screen>

    <para>Compile the package:</para>

<screen><userinput remap="make">make</userinput></screen>

    <para>Install the package:</para>

<screen><userinput remap="install">make DESTDIR=$PWD/DESTDIR install
cp -a DESTDIR/usr/libx32 $LFS/usr/
install -vm644 DESTDIR/usr/include/gnu/{lib-names,stubs}-x32.h \
               $LFS/usr/include/gnu/
ln -svf ../libx32/ld-linux-x32.so.2 $LFS/lib/ld-linux-x32.so.2</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(){}' &gt; dummy.c
$LFS_TGT-gcc -mx32 dummy.c
readelf -l a.out | grep '/ld-linux-x32'</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: /libx32/ld-linux-x32.so.2]</computeroutput></screen>

      <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.</para>

      <para>Once all is well, clean up the test files:</para>

<screen><userinput>rm -v dummy.c a.out</userinput></screen>

    </caution>

  </sect2><!-- mx32 -->

  <sect2 role="content">
    <title/>

    <para>Details on this package are located in
    <xref linkend="contents-glibc" role="."/></para>

  </sect2>

</sect1>