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. IMPORTANT: In the following documentation, gnupro-98r2 is the input (as the current version of GNUPro Toolkit) to substitute for the variable, release_name. You'll need to provide the following specifications when rebuilding: Where to install the binaries; see Configuring the location of the tools. Which target system will run your final target machine's code; see Configuring when using an embedded target. Preparing sources so that you get what you expect; see Preparing to rebuild source code files Then see Building and installing binaries. 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. To install GNUPro Toolkit in /opt/cygnus/release_name, use the following example's directive. --prefix=/opt/cygnus/release_name To install GNUPro Toolkit in /usr/cygnus/release_name, use the following example's directive. --prefix=/usr/cygnus/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. --prefix=/usr/cygnus/release_name --exec-prefix=/usr/cygnus/release_name/H-host --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. Warning! The values of both --prefix= and --exec-prefix= must be absolute pathnames. 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. Note: To build a native toolkit, do not use the --target= option. For instance, programs such as the GNU debugger or the GNU compiler will run on an IRIX 5 system and output programs which also run on an IRIX 5 system. In this situation, the --target= option is unnecessary. configure will default to native configuration when using --target. Warning! For VxWorks users building a cross toolkit with the target board running the VxWorks from Wind River Systems, remember to add the --with-includes= command option to configure, designating the value for header files with your VxWorks distribution. If the VxWorks tools are in /opt/wrs/vxworks-5.2/ , then the header files are probably in /opt/wrs/vxworks-5.2/h . Add the --with-includes=/opt/wrs/vxworks-5.2/h command option when you run configure . If you do not add this command line option, your toolchain will not work. 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 /opt/cygnus directory. The build process may take hundreds of megabytes of disk space. Warning! 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 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.   /usr/cygnus/release_name/build To configure a native toolchain, use the following example.     %  mkdir /usr/cygnus/release_name /build     %  cd    /usr/cygnus/release_name /build     %        /usr/cygnus/release_name/src/configure                --prefix=/opt/cygnus/release_name   To configure a toolchain in /opt/cygnus for a Motorola 68000 target with ELF output file format, use the following example's steps.   %  mkdir  /usr/cygnus/release_name/build   %  cd   /usr/cygnus/release_name/build   %  /usr/cygnus/release_name/src/configure  --target=m68k-elf\         --prefix=/opt/cygnus/release_name Note: --target= is only for cross development. --target= is unneccessary for native configuration. configure will default to native configuration when using --target. 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 2. Then, use the following instruction to run make . % /usr/local/bin/make all This takes a while to complete.   3. When make all finishes, install the tools with the following input. % /usr/local/bin/make install When you have verified that your toolchain is functioning properly, you may remove the build directory to conserve disk space. 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. /usr/cygnus/release_name/H- m68k-elf 2. Then, place all the programs that run on PowerPC systems in the following location. /usr/cygnus/release_name/H-powerpc-ibm-aix4.2 This shares the man pages, text configuration files, and other files for GNUPro Toolkit. 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. Use the --version option for telling which version you are running; if you have this error message, run the command, make --version . If you are not using GNU make , the make program will not recognize the - -version option. Incorrect compiler used When configure runs, it looks for an appropriate compiler, first gcc, then 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. The following example is the input for the appropriate path for the GCC compiler.      /usr/cygnus/gnupro-98r2/bin/gcc   With a C shell, use a command similar to the following example's input (where /opt/vendor/bin/ is the path of the compiler, not-your-usual-cc). % set CC /opt/vendor/bin/not-your-usual-cc % configure ... % make   With a Bourne shell (/bin/sh ) or a Korn shell, use the following example's input (where /opt/vendor/bin/ is the path of the compiler, not-your-usual-cc). % CC= /opt/vendor/bin/not-your-usual-cc % export CC % configure ... % make   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. 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 (where /release_name is the version name of the GNUPro Toolkit which you are using). % rm -rf /usr/cygnus/release_name/build % mkdir /usr/cygnus/release_name/build 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 /usr/cygnus/release_name/build/config.status . 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). IMPORTANT: Use "build" for your category when creating a new problem's report. 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. Send the top-level config.status file. This file will indicate which command line options were used to configure the toolkit. Using the example pathnames that we've used, find the file at /usr/cygnus/release_name/build/config.status . Send the output of the make command that is failing. Only the output from the last directory is probably useful, just as with a configure problem report. If in doubt, send the entire output from make and Cygnus technical support staff will determine the problem and resolve it. 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. patch -p < /tmp/patch 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. 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-pasting methods. 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. % find . -name `*.rej' -print Top|Contents|Previous