Red Hat Docs  >  Manuals  >  GNUPro Toolkit Manuals  > 

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8. Rebuilding the Tools

Red Hat may provide updates to this release in the form of source code patches. Once these patches are applied, you will need to rebuild the binaries before the update can be used. The following documentation details the instructions for rebuilding this release using the Red Hat gnupro-03r1 native compiler.

Following is an outline of the process for rebuilding:

The amount of disk space required for rebuilding varies depending on the filesystem used. Red Hat recommends at least 2GB of free disk space for the source code, the build directory, and the new installation directory.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.1 Setting up the Native Environment

This release was built using the GNUPro 2003 release. You should have already received a copy of GNUPro 2003 for all of your supported hosts. If you do not have a copy of GNUPro 2003, please contact your account representative to receive a copy.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.1.1 gnupro-03r1 requirements

If you are installing gnupro-03r1 from the CD, be sure to install the compiler, misc, and utils packages at a minimum. Cygwin users will also need the Contributed Binaries package. By default your installation will be in /opt/redhat/gnupro-03r1. The remainder of these instructions will be based upon this path so adjust it as needed.

Once GNUPro is installed, you'll need to add the path to the compiler to your shell. GNUPro supports a variety of operating systems, so the path used depends on what operating system is used. Follow the general instructions in Set Environment Variables. More in detail:

For Solaris 7, the path would be:
 
/opt/redhat/gnupro-03r1/H-sparc-sun-solaris2.7/bin

Using csh syntax, the command to add the path is:

 
set path = ( /opt/redhat/gnupro-03r1/H-sparc-sun-solaris2.7/bin $path )

Using sh syntax, the command to add the path is:

 
PATH=/opt/redhat/gnupro-03r1/H-sparc-sun-solaris2.7/bin:$PATH

You are now ready to use gnupro-03r1.

WARNING!
{Do not use an environment from another Cygwin, UNIX or
GNU/Linux release; doing so will cause problems rebuilding and subsequently using the tools.}

IMPORTANT
{In the following instructions, substitute the actual name
for the release instead of RELEASE_NAME}.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.2 Configuring, Building, and Installing the Tools

Use the following steps for configuring, building and installing. Do not continue to the next step unless the previous steps are successful. If a step fails for any reason, save a copy of the exact error message as a file (cut and paste, screen dump, etc.) along with any relevant log files and submit them in a bug report.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

8.2.0.1 Set up the build area

Keeping projects tidy will keep everything to a minimum of confusion. By making a tree of directories for your different builds it s easy to keep track of what you re working on.

  1. Start a bash shell with the bash command from a shell window (from a MS-DOS console with Cygwin). The following example shows what you will see in the window (typing bash after your standard prompt, you get a bash-2.04$ prompt). ). The following example shows what you will see in the window (typing bash after the C:\> prompt, you get a bash-2.04$ prompt).

    Unix or GNU/Linux
     
    bash   ( or C:\> bash     in Cygwin)
    bash-2.04$
    

    Cygwin
     
    C:\> bash
    bash-2.04$
    

  2. From a bash-2.04$ prompt, create a project directory for yourself. As an example, make a directory called project in your home directory:

     
    mkdir ~/project
    

  3. Then, make a build directory under that directory to hold object files:

     
    mkdir ~/project/build
    

  4. Then, change directories into ~/project:

     
    cd ~/project
    

  5. Lastly, install the source code via the graphical installer or according to the README from an FTP shipment. GNUPro-03r1 releases have two sets of sources in directories named src-cross and src-native for cross tools and native tools respectively (Host-x-host configurations use src-native).

    You are now ready to configure and build the toolchain.


    [ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

    8.2.0.2 Run configure

    1. Change directories to ~/project/build:

       
      cd ~/project/build
      

    2. Execute PREFIX/src-TYPE/configure with all the necessary flags where PREFIX is the complete path to the sources and TYPE is either cross or native. Necessary flags include a minimum:

       
      --host=host-triplet \
       --target=target-triplet \
       --prefix=~/project/install \
       --exec-prefix=~/project/install/H-host-triplet
      

      The previous input is all one line before using the Enter key (the backlashes, \, signify line breaks for this text's display requirements).

      When configuring a native compiler, the target option may be omitted. In this case the target will default to being the same as the host.

      When configuring Linux and Solaris native compilers, one may optionally enable the sys-root option. A sys-rooted compiler allows a developer to use one version of Linux or Solaris but create executables for a different version. This option can be enabled by adding --with-sysroot to the command line arguements passed to configure.

    The target and host triplets vary depending on the release; please see below for a list of supported triplets. The example prefix is where the new toolchain will be installed; the exec prefix is where architecture-dependant files will be installed. You may want to redirect STDOUT and STDERR to a file. A complete configure line for the sparc-sun-solaris2.7 hosted toolchain might appear thus:

     
    ~/project/src/configure --host=sparc-sun-solaris2.7 \
     --target=TOOLPREFIX --prefix=~/project/install \
     --exec-prefix=~/project/install/H-sparc-sun-solaris2.7 \
     >& ../configure.log
    

    This will configure the system to install in ~/project/install with the executables sitting in ~/project/install/H-sparc-sun-solaris2.7/bin.

    example \text\{Running the configure command from the build directory on UNIX, Running the configure command from the build directory on UNIX}, shows what you will see after completing the input in the build directory. Replace host (where host signifies the toolchain's triplet name) with the host triplet for your toolchain.

    /build_dir/redhat/RELEASE_NAME/ is an example for a directory from which to execute the configure command.

    WARNING!
    Never run the configure
    directory!

    WARNING!
    Never rerun the configure
    build_dir directory! Always start from scratch.

    Example \text\{Running the configure command from the build directory on
    UNIX, Running the configure command from the build directory}

     
    bash-2.04$ /opt/redhat/RELEASE_NAME/src-TYPE/configure -v  \
    --prefix=/build_dir/redhat/RELEASE_NAME                     \
    --exec-prefix=/build_dir/myredhat/RELEASE_NAME/H-host \
    --host=host                                            \
    --target=target                                          \
    > configure.log 2>&1 &
    

    The previous input is all one line before using the Enter key (the backlashes, \, signify line breaks for this text's display requirements).

    You can view the configure output using a tail -f configure.log command as the previous example shows; use the Ctrl-C key sequence to exit the tail process.

    The following tasks are the fundamentals of the process of ensuring that your configuration works:

    Table \text\{Supported host-triplet target-triplet combinations,
    Supported host-triplet target-triplet combinations}

    sparc-sun-solaris2.5
    sparc-sun-solaris2.6
    sparc-sun-solaris2.7
    sparc-sun-solaris2.8
    sparc-sun-solaris2.9
    sparc64-sun-solaris2.7
    sparc64-sun-solaris2.8
    sparc64-sun-solaris2.9
    i686-pc-linux-gnulibc2.1
    i686-pc-linux-gnulibc2.2
    i686-pc-linux-gnulibc2.3
    powerpc-unknown-linux-gnu
    hppa1.1-hp-hpux10.20
    hppa1.1-hp-hpux11.00
    i686-pc-cygwin
    powerpc-ibm-aix4.3.3.0
    powerpc-ibm-aix5.1.0.0
    alphaev56-dec-osf5.1
    mips-sgi-irix6.5
    sparc-sun-solaris2.6 powerpc-eabi
    sparc-sun-solaris2.6 mips-elf
    sparc-sun-solaris2.6 mipsisa32-elf
    sparc-sun-solaris2.6 arm-elf
    sparc-sun-solaris2.6 mips64-elf
    i686-pc-linux-gnulibc2.1 powerpc-unknown-linux-gnu
    i686-pc-linux-gnulibc2.2 powerpc-eabi
    i686-pc-linux-gnulibc2.2 arm-elf
    i686-pc-linux-gnulibc2.2 mips-elf
    i686-pc-linux-gnulibc2.2 mips64-elf
    i686-pc-linux-gnulibc2.2 mipsisa32-elf
    i686-pc-linux-gnulibc2.3 powerpc-eabi
    i686-pc-linux-gnulibc2.3 arm-elf
    i686-pc-linux-gnulibc2.3 mips-elf
    i686-pc-linux-gnulibc2.3 mips64-elf
    i686-pc-linux-gnulibc2.3 mipsisa32-elf
    i686-pc-cygwin mips-elf
    i686-pc-cygwin mips64-elf
    i686-pc-cygwin mipsisa32-elf
    i686-pc-cygwin arm-elf
    i686-pc-cygwin powerpc-eabi


    [ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

    8.2.0.3 Sys-roots and Rebuilding

    A sys-root is a directory containing portions of a Unix system's libraries and headers, maintaining the original directory layout. Where Unix systems have a /lib, /usr/lib, and /usr/include, a system root has a file for file identical sys-root/lib, sys-root/usr/lib, and sys-root/usr/include directory.

    A typical system root contains all the headers and libraries available in /lib, /usr/lib, /usr/include, /usr/X11R6/lib, and /usr/X11R6/include. Copying all this can take up a large amount of disk space, so copying just the files one needs is often a good idea. For example, if no X11 software is going to be built, the header and libraries from /usr/X11R6 can completely excluded.

    When creating a toolchain with the --with-sysroot option, the sys-root must be created before building the tools themselves. The sys-root is located in a directory named sys-root. This directory is located under the named target triplet directory which resides directly below the exec-prefix path.

    As an example, the GNUPro-03r1 i686-pc-linux-gnulibc2.2 exec prefix is /opt/redhat/gnupro-03r1/H-i686-pc-linux-gnulibc2.2. The target triplet is i686-pc-linux-gnulibc2.2. Thus, put together, its sys-root is in /opt/redhat/gnupro-03r1/H-i686-pc-linux-gnulibc2.2/i686-pc-linux-gnulibc2.2/sys-root.

    One can either create the sys-root directory in this deep path or use a symlink to point to the sys-root you'd like to use. Using a symlink has the advantage that it's easy to build multiple versions of a toolchain, but use the same sys-root for all of them.


    [ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

    8.2.0.4 Run make

    Use the make tool to build the binaries and info files.

    WARNING!
    If building a native compiler using the --with-sysroot
    option, be sure to populate the sys-root first! See Sys-roots and Rebuilding for more information.

     
    make -w all info > make.log 2>&1 &
    


    [ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

    8.2.0.5 Install the Built Toolchain

    Use the make tool to install the binaries and info files.

     
    make -w install install-info > install.log 2>&1 &
    


    [ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

    8.2.0.6 Ensure Completion of Rebuild Process

    Test that the newly rebuilt tools work with the following instructions (which by no means show a comprehensive test).

    1. Start a bash shell with the bash command from a shell window (or from an MS-DOS console for Cygwin); typing bash after the prompt, you get a bash-2.04$ prompt.

    2. Add the new installation binaries to the PATH environment variable information as the following example shows. Replace host (where host signifies the toolchain's triplet name) with the host triplet for your release.

       
      export PATH=/build_dir/redhat/RELEASE_NAME/H-host/bin:$PATH
      

    3. Create a "Hello World" program with the following input:

       
      cat > hello.c
      extern int printf(__const char *format, ...);
      int main () { printf("Hello World!\n"); }
      

      Use the Ctrl-D key sequence to exit the process.

    4. Compile the "Hello World" program.

       
      TOOLPREFIX-gcc -Wall hello.c -o hello.x
      

    5. Execute the "Hello World" program.

       
      TOOLPREFIX-run hello.x
      

      At the bash-2.04$ prompt, see the following output.

       
      Hello World!
      

    Rebuilding is complete.


    [ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

    8.3 Patching

    After submitting a support request, your solution may come in the form of a patch (a solution that mends the problem). To apply a patch to your source code, you need to navigate to the source directory (use the cd command to change to the /src directory). /opt/redhat/ instdir /src is the full default pathname for the source directory. Save the patch as a /tmp/patch file, and run the patch program like the following example's declaration shows.

     
    patch -p < /tmp/patch
    

    You do not need to edit out all the non-patch text from the /tmp/patch file; the patch program will recognize where the real patch begins.

    If the patch is rejected, there will be a filename ending in .rej in the source directory; for instance, if the patch was for a file in the src/gcc/reload.c path, and the patch was rejected, src/gcc/reload.c.rej is the rejection found there. Although it will take a while to run, you can search all files for a rejected patch with a command like the following example.

     
    find . -name *.rej -print
    

    IMPORTANT
    {Do not cut-and-paste the patch with a windowing system like
    X-Windows; tab characters are important and they are usually not preserved correctly when using cut-and-paste methods.}

    See also Invoking patch and Options to patch in Using diff & patch in GNUPro Development Tools.


    [ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

    8.4 Troubleshooting the Rebuilding Process

    The following documentation discusses warnings or error messages that may display during your build process. Each message has a troubleshooting approach accompanying it for resolution of the problem that you re addressing. If the problem's cause is still unclear, send in a problem report; See How to Report Problems. The following warnings or error messages may display.

    Make: Fatal error: Don t know how to make target foo.c
    The most likely problem is that you are not using GNU make. Use the --version option for telling which version you are running; if you have this error message, run the make --version command. If you are not using GNU make, the program will not recognize the --version option.

    Incorrect compiler used
    When configure runs, it looks for an appropriate compiler, first GCC, then another C compiler, cc. If neither of these is correct, specify the name of the compiler at configuration time. We recommend that you always build with the GNU compiler, using the gcc command. Specify the compiler by setting the $CC environment variable before running configure.

    • With a C shell, use a command similar to the following example's input (where /installdir /bin/ is the path to the compiler, not-your-usual-cc).

       
      setenv CC /installdir/bin/not-your-usual-cc configure ...
      make
      

    • With a Bourne shell (/bin/sh) or a Korn shell, use the following example's input (where /installdir /bin/ is the path of the compiler, not-your-usual-cc).

       
      CC=/installdir/bin/not-your-usual-cc export CC configure ...
      make
      

    If you still experience configuration problems, first try to rerun configure by adding the --verbose command line option. It's best to redirect the output to a log file while running this process.

    • With a C shell, use a command similar to the following example's input.

       
      configure --verbose ... >& configure.out
      

    • With a Bourne shell, use the following example's input.

       
      configure --verbose ... >configure.out 2>&1
      

    Some seemingly unrelated problems arise after applying patches or making other changes. For instance, sometimes file dependencies get confused. With any trouble you have building, an easy step to take is to remove your build directory completely and then rebuild in an empty build directory, using input like the following example.

     
    rm -rf /opt/redhat/instdir/build
    mkdir /opt/redhat/instdir/build
    

    Then install GNUPro Toolkit; See Installing GNUPro Toolkit.

    If it's not obvious which part of the toolkit is failing, check the last line in the log that begins Configuring... (such as with the debugging tool, GDB, where you d see the Configuring gdb... status message) before the processing for the configure command stops.

    configure also creates a config.log file in each sub-directory in which it runs tests. Check the end of the config.log that failed for specific information about what went wrong. The last 25-30 lines of this file should be adequate to diagnose the failure.


    [ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

    8.5 configure Problem Reporting

    If the problem's cause is still unclear, submit a support request; see How to Report Problems. If your configuration problems are still unsolved, send in the configure file's top-level config.status file. This file shows which command line options were used to configure the toolkit.

    /opt/redhat/instdir/build/config.status should be the path to config.status (assuming the example pathnames here). The --verbose option for configure produces the entire output from the last directory. For instance, if configure fails in the GNU assembler directory, when creating a problem's case, provide everything after the line which reads Configuring gas... and, if in doubt, with the case report, provide a copy of all the output that generated from the configure --verbose input, so that technical support staff can more easily determine the problem and quickly resolve it.


    [ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

    8.6 build Problem Reporting

    If your build problems are still confusing, report the build problem; How to Report Problems. Use build for your category when creating a new case when submitting a support request. First, verify that you re using GNU make, as outlined in the Make: Fatal error: Don t know how to make target foo.c error (see Troubleshooting the Rebuilding Process).

    The following information is vital when you report the problem.


    [ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

    This document was generated by Brendan Conoboy on June, 5 2003 using texi2html