| Red Hat Docs > Manuals > GNUPro Toolkit Manuals > |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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] | [ ? ] |
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] | [ ? ] |
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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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] | [ ? ] |
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.
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$ |
bash-2.04$ prompt, create a project directory for
yourself. As an example, make a directory called project in your home
directory:
mkdir ~/project |
mkdir ~/project/build |
cd ~/project |
You are now ready to configure and build the toolchain.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
~/project/build:
cd ~/project/build |
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.
directory!
build_dir directory! Always start from scratch.
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:
configure generates a Makefile in each relevant source directory,
for use by the GNU make tool to use when you build applications.
configure establishes and populates build directories for your
application's compiled code to reside.
configure creates an initialization file in the build directory
in order to exchange information with the GNU debugger when you debug your
applications.
configure provides a shell script, config.status, for
reconfiguration use.
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] | [ ? ] |
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] | [ ? ] |
Use the make tool to build the binaries and info
files.
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] | [ ? ] |
Use the make tool to install the binaries and info files.
make -w install install-info > install.log 2>&1 & |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Test that the newly rebuilt tools work with the following instructions (which by no means show a comprehensive test).
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.
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 |
"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.
"Hello World" program.
TOOLPREFIX-gcc -Wall hello.c -o hello.x |
"Hello World" program.
TOOLPREFIX-run hello.x |
At the bash-2.04$ prompt, see the following output.
|
Rebuilding is complete.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 |
See also Invoking patch and Options to patch in
Using diff & patch in GNUPro
Development Tools.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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
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
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.
/bin/ is the path to the compiler,
not-your-usual-cc).
setenv CC /installdir/bin/not-your-usual-cc configure ... make |
/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.
configure --verbose ... >& configure.out |
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] | [ ? ] |
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] | [ ? ] |
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.
config.status file, which will indicate the
command line options that you used to configure. Find the file in the
/opt/redhat/instdir/build/config.status directory.
make command. Only the output
from the last directory is probably useful, as with a configure
case report. If in doubt, send the entire output from make and
technical support staff will determine the problem and resolve it.
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |