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.
In the following
documentation, gnupro-99r1 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:
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
/yourdirectory/cygnus/release_name,
use the following example's directive.
--prefix=/yourdirectory/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.
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.
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.
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 /yourdirectory/wrs/vxworks-5.2/, then the
header files are probably in the /yourdirectory/wrs/vxworks-5.2/h
directory.
Add the --with-includes=/yourdirectory/wrs/vxworks-5.2/h
command
option when you use the configure input. 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 /yourdirectory/cygnus directory.
The build process
may take hundreds of megabytes of disk space.
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=/yourdirectory/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=/yourdirectory/cygnus/release_name
--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 .
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.
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-99r1/bin/gcc
-
With a C shell, use a command
similar to the following example's input (where /yourdirectory/vendor/bin/
is the path of the compiler, not-your-usual-cc).
set
CC /yourdirectory/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 /yourdirectory/vendor/bin/
is the path of the compiler, not-your-usual-cc).
CC=
/yourdirectory/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 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).
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.
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.
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