Contents|Previous
Rebuilding from source 
The following documentation explains how to rebuild the GNUPro tools using the binary files from source installation, and how to configure your system before you rebuild the binaries from source code for a specified toolchain.
You'll need to provide the following specifications when rebuilding:
For any problems, see Accessing Cygnus Web Support to report problems, and, also, see Troubleshooting the rebuilding process, configure problem reporting, and build problem reporting.
Finally, see Patching for details on correcting the problems.

Configuring the location of the tools

The --prefix= option specifies the base installation path for the entire toolkit. In the following descriptions, the name of your current GNUPro software release is written in italics as release_name.
GNUPro binaries are typically located in /usr/cygnus/release_name.
To rebuild GNUPro Toolkit and install it in the same location as the Cygnus binaries, use the following input.
--exec-prefix=is useful for sites with multiple host architectures in a networked, shared file system. See also Multiple host builds. host stands for the canonical name describing the host. For instance, for a SPARC Solaris 2.5 system, "sparc-sun-solaris2.5" is the canonical name. For a complete listing of the current hosts and their canonical naming conventions, see Naming hosts and targets.

Configuring when using an embedded target

If you are targeting an embedded system, remember at configure time to specify the --target= option. The --target= option value is printed on the CD-ROM you receive from Cygnus. It will be a hyphenated string indicating target and output format.
For example, m68k-elf or powerpc-eabi would be two such target names with their appropriate output file formats for, respectively, the Motorola 68000 family of processors and the PowerPC series of processors.

Preparing to rebuild source code files

The first and most important step in preparing source code to run on your system is to configure it so that, when built, the program exhibits the behavior you expect. The configuration process automatically prepares a Makefile containing default and/or 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 normally in /usr/cygnus/release_name/src . Good practice is to configure and build the source in another directory; any other clean directory will do. In the following examples of commands, the path is from the /yourdirectory/cygnus directory.
The build process may take hundreds of megabytes of disk space.
The default action for configure is to configure a native toolchain for the host on which you run the script. At minimum, specify --prefix= to point to your installation directory. For cross-compiler toolchains, you must also specify --target. The following examples use a directory for the build location with the following name.
To configure a native toolchain, use the following example.
To configure a toolchain in /opt/cygnus for a Motorola 68000 target with ELF output file format, use the following example's steps.
Expect configure to take approximately 15-45 minutes to run, depending on the load of your build system, the toolchain being configured and the sources used.

Building and installing binaries

After you configure the toolchain, build and install the binary programs. 
For single host-target builds, see Single host-target builds for details.
For multiple host builds, see Multiple host builds for details.
Some vendor-supplied make programs do not build the toolkit correctly, 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 in Using make in GNUPro Utilities.

Single host-target builds

In the following example, a copy of GNU make is in /usr/local/bin and is called make.
    1. Move to the build directory, using instructions like the following input.
        cd /usr/cygnus/release_name/build

Multiple host builds

GNUPro Toolkit is designed for a kind of multiple-host environment. Set up the tools this way by adding a --exec-prefix= command line option to configure when configuring the toolkit. This then allows having a directory named /usr/cygnus/release_name, with multiple hosts and target versions in one place.
The host-specific files will then be in /usr/cygnus/release_name/H-hostspec. hostspec stands for the canonical name describing the host. For instance, for a SPARC Solaris 2.5 system, "sparc-sun-solaris2.5" is the canonical name.
Consider, then, using the GNUPro tools. A compiler, for whatever target it addresses, is a host-specific program, meaning that it only runs on one host system. A help file is host-independent and it is independent of its host system.
So, imagine you have, for instance, Motorola 68000 systems and IBM PowerPC running AIX 4.2 on one network. There is support for native compilers on both systems, and you want a single /usr/cygnus directory that can be NFS-mounted on all of your machines. You should then use the following process.
    1. Place all the programs that run on Motorola 60000 systems using the ELF object file format in the following location.

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 cause of the problem is still not clear, send in a problem report. For a complete description of the automatic problem reporting system, see How to report problems and, to report a problem, see Accessing Cygnus Web Support.

Error messages and warnings

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.
Incorrect compiler used
If you still experience configuration problems, first try to rerun configure by adding the command line option, --verbose. It's best to redirect the output to a log file while running this process.
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 (where /release_name is the version name of the GNUPro Toolkit which you are using).
For more information on installing 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 status message, "Configuring gdb..." before configure 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 page (25-30 lines) of this file should be plenty, but if in doubt, send the entire file. For help, contact Cygnus. For information on contacting Cygnus technical support, see How to contact Cygnus.

configure problem reporting

If the cause of the problem is still not clear, send in a problem report.
For a complete description of the automatic problem reporting system, see How to report problems.
If your configuration problems are still confusing, send in the configure file's top-level config.status file. This file shows which command line options were used to configure the toolkit.
config.status (assuming the example pathnames we've used) should be in the /usr/cygnus/release_name/build/config.status directory.
The --verbose option for configure produces the entire output from the last directory. For instance, if configure fails in the gas directory, send in everything after the line which reads "Configuring gas..." and, if in doubt, send us a copy of all the output generated by configure --verbose; so that Cygnus technical support staff can more easily determine the problem and quickly resolve it.

build problem reporting

If your build problems are still confusing, report the build problem (see Accessing Cygnus Web Support).
First, verify that you're using GNU make, using the process outlined in the examples with the "Make: Fatal error: Don't know how to make target foo.c " error (see Error messages and warnings).
 
Cygnus Support staff representatives need the following information when you report the problem.

Patching

After submitting a problem's report to Cygnus, your solution is known as a patch.
To apply a patch to your source code, you will need to move to the source directory (using the shell commandline declarations, cd into the src directory). The full default pathname for the source directory is /usr/cygnus/release_name/src. Save the patch as a file, such as /tmp/patch, and run the patch program.
You do not need to edit out all the non-patch text from the file, /tmp/patch . The patch program will recognize where the real patch begins.
See also Invoking patch and Options to patch in Using diff & patch in GNUPro Utilities. 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.
Top|Contents|Previous