This chapter explains how to rebuild using binary files from a source installation, as well as how to configure your system before you rebuild the binaries from source code for a specified set of tools.
Substitute the current version of GNUPro Toolkit's name ( gnupro-02r1) for the installdir variable as the location where you installed the tools (if other than the default path).
For Microsoft Windows systems, see Rebuilding When Compiling with Microsoft Windows NT Systems
For any problems, see Troubleshooting the Rebuilding Process, configure Problem Reporting, and build Problem Reporting. See Patching for details on correcting the problems.
You specify the base installation path for the toolkit by using --prefix= option
GNUPro binaries are typically located in /opt/redhat/gnupro-02r1/src.
To rebuild the GNUPro Toolkit and install it in the same location as the binaries, use:
--prefix=/opt/redhat/instdir/
--exec-prefix=/opt/redhat/instdir/H-host
The option --exec-prefix= is useful for sites with multiple host architectures in a networked, shared file system (a heterogeneous network--see Multiple Host Builds). host stands for the canonical name describing the host. For example, a Linux system has i686-pc-linux-gnulibc2.1 (for Red Hat Linux 6.x) or i686-pc-linux-gnulibc2.2 (for Red Hat Linux 7.x) as the canonical name. For a complete listing of the current hosts and their canonical naming conventions, see Naming Conventions and Table 1, Naming hosts with their canonical names.
The values of both --prefix= and --exec-prefix= must be absolute pathnames.
If you are targeting an embedded system, remember at configure time to specify a --target= option. The value for the --target= option is on the CD-ROM you receive (a hyphenated string indicating target and output format); see also Embedded Cross-configurations. For example, powerpc-eabi would be the target name with the appropriate output file format for the PowerPC series of processors.
To build a native toolkit, do not use a --target= option. For instance, programs such as the GNU debugger or the GNU compiler will run on a MIPS target; if you want programs to run on a MIPS target, the --target= option is unnecessary because configure defaults to the native configuration when using the --target= option.
In preparing source code to run on your system, the first and most important step is to configure it so that the built program exhibits the behavior you expect. The configuration process automatically prepares a Makefile containing default information or default and customized information for your site and for your system.
If you are building for more than one platform, you must configure, compile, and install on each platform. Source code is usually in the /opt/redhat/instdir/src directory; any empty directory will do. In the following examples of commands, the path is from the installdir / directory.
Never build your toolkit in the source directory!
Rebuilding in your source directory will overwrite Makefiles, prohibiting reconfiguration.
The default action for configure is to configure a native set of tools for the host on which you run the script. At minimum, specify --prefix= to point to your installation directory. You should also specify the host when configuring; you specify a host with " configure -- host=host-triplet ". If you do not specify the host, the configure script will have to guess and may get it wrong. For example, a Solaris2.7 system can be either sparc-sun-solaris2.7 or sparc64-sun-solaris2.7. If you do not specify which to use, gcc uses sparc-sun-solaris2.7.
The hosts for this release are:
The following examples use a directory for the build location with the /opt/redhat/ instdir/ build name.
To configure a native set of tools, use the following example.
mkdir /opt/redhat/
instdir/
build
cd /opt/redhat/instdir/build
/opt/redhat/instdir/src/configure --prefix=/installdir/
To configure a set of tools in installdir redhat for a PowerPC target with EABI output file format, use:
mkdir /opt/redhat/
instdir/
build
cd /opt/redhat/
instdir/
build /opt/redhat/instdir/src/configure --target=powerpc-eabi --prefix=/installdir
Expect configure to take approximately 15-45 minutes to run, depending on the load of your build system, the set of tools that you configure, and the sources you use. The build process may take hundreds of MBs of disk space.
After you configure the tools, you build and install the binary programs; see either Single Host Builds or Multiple Host Builds as appropriate.
Some make reconfiguration programs do not do what you might expect, so, for simplicity, use GNU make to rebuild from source. A precompiled copy of GNU make is in GNUPro Toolkit. If you are not familiar with make, see Using make in GNUPro Utilities.
In the following example, a copy of GNU make uses the /usr/local/bin path.
/opt/redhat/instdir/bin/make all
This takes a while to complete.
/opt/redhat/instdir/bin/make install
You may also add information to the make
GNUPro Toolkit is designed for multiple-host environments.
Set up the tools by adding a --exec-prefix= option when configuring, allowing for a /opt/redhat/instdir/ directory with multiple hosts and target versions in one place. Host-specific files will then be in the /opt/redhat/instdir/H-host directory (host signifying the canonical name describing the host system); for instance, a Red Hat Linux 6.2 system has i686-pc-linux-gnulibc2.1 as the canonical name (see Table 1, Naming hosts with their canonical names for names).
You want to use the GNUPro compiler and its tools for the target you want to address for a host-specific program. (This means that the program only runs on one host system; because it is host-independent, it is independent of its host system.) Imagine you have, for instance, a Red Hat Linux 6.2 system and a Solaris SPARC 2.6 system running on one network with support for native compilers on both systems, and you want a single /opt/redhat/instdir/ directory that can be NFS-mounted on all of your machines. You can do this as follows:
/opt/redhat/instdir/H-i686-pc-linux-gnulibc2.1
/opt/redhat/instdir/H-sparc-sun-solaris2.6
This shares the man pages and text configuration files, among other requirements.
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 by using the cd command. /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 as follows:
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 example, 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 similar to the following:
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 "Invoking patch " and "Options to patch " in Using diff & patch in GNUPro Development Tools.
The following examples show the C: drive as default; substitute the appropriate corresponding drive letter for the drive you use.
Do not use other Cygwin installations from another release, including any Internet release. Their contents may not be appropriate for your release.
To rebuild the tools on a Microsoft Window NT system's C: drive:
mkdir gnupro-02r1
cd gnupro-02r1
cd ..
mkdir
projectname
cd
projectname
move c:\cygwint1.bat .
move c:\cygwint1mount.bat .
cygwint1.bat
cygwint1mount.bat
bash
If either cygwint1.bat or cygwint1mount.bat give error messages, the bash shell may not behave as expected. The cygwint1.bat sets your system path, and the cygwint1mount.bat sets important file system mounts. They must be executed in the order specified. If either of them yield errors, you may have problems later.
If you decide not to use these example directory names (cygwin-02r1, builddir and installdir in these steps), you will need to modify the .bat files according to your changes.
/cygdrive/c/redhat/gnupro-02r1/configure --host=i686-pc-cygwin \
--prefix=/cygdrive/c/installdir \
--exec-prefix=/cygdrive/c/installdir/H-i686-pc-cygwin \
Watch what the configure.log file produces in another window by using a tail -f command in your projectname directory after starting bash. Use the cygwint1.bat, cygwint1mount.bat, bash method to start as many bash windows as you require. At a minimum, have at least two bash windows open: one in which to execute the configure, build, and install process, and another in which to watch the progress using the tail -f filename .log command.
make install >& ../install.log
At this point, you should have three log files in your projectname directory. This allows you to save disk space by eventually deleting your build directory without losing your logs of the build process. Do not delete your build directory until after the build process is complete and after you are confident that the tools work correctly.
This section 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 are 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.
setenv CC
/installdir
/bin
/not-your-usual-cc
configure
...
make
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 is 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 commands similar to the following:
rm -rf /opt/redhat/instdir/build
mkdir /opt/redhat/instdir/build
Then install GNUPro Toolkit; see Installing GNUPro Toolkit.
If it is 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 wou;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.
If the problem's cause is still unclear, submit a support request as described in 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, provide a copy of all the output that generated from the configure --verbose input with the case report so that technical support staff can more easily determine the problem and quickly resolve it.
If your build problems are still confusing, report the build problem as described in How to Report Problems. Use build for your category when creating a new case when submitting a support request. First, verify that you are 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.