URL
https://opencores.org/ocsvn/or1k/or1k/trunk
Subversion Repositories or1k
[/] [or1k/] [trunk/] [gdb-5.3/] [etc/] [configure.info-3] - Rev 1779
Go to most recent revision | Compare with Previous | Blame | View Log
This is configure.info, produced by makeinfo version 4.1 from
./configure.texi.
INFO-DIR-SECTION GNU admin
START-INFO-DIR-ENTRY
* configure: (configure). The GNU configure and build system
END-INFO-DIR-ENTRY
This file documents the GNU configure and build system.
Copyright (C) 1998 Cygnus Solutions.
Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.
Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided that
the entire resulting derived work is distributed under the terms of a
permission notice identical to this one.
Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that this permission notice may be stated in a
translation approved by the Foundation.
File: configure.info, Node: Multilibs in Target Libraries, Prev: Multilibs in gcc, Up: Multilibs
Multilibs in Target Libraries
=============================
The target libraries in the Cygnus tree are automatically built with
multilibs. That means that each library is built multiple times.
This default is set in the top level `configure.in' file, by adding
`--enable-multilib' to the list of arguments passed to configure when
it is run for the target libraries (*note Host and Target Libraries::).
Each target library uses the shell script `config-ml.in', written by
Doug Evans, to prepare to build target libraries. This shell script is
invoked after the `Makefile' has been created by the `configure'
script. If multilibs are not enabled, it does nothing, otherwise it
modifies the `Makefile' to support multilibs.
The `config-ml.in' script makes one copy of the `Makefile' for each
multilib in the appropriate subdirectory. When configuring in the
source directory (which is not recommended), it will build a symlink
tree of the sources in each subdirectory.
The `config-ml.in' script sets several variables in the various
`Makefile's. The `Makefile.in' must have definitions for these
variables already; `config-ml.in' simply changes the existing values.
The `Makefile' should use default values for these variables which will
do the right thing in the subdirectories.
`MULTISRCTOP'
`config-ml.in' will set this to a sequence of `../' strings, where
the number of strings is the number of multilib levels in the
source tree. The default value should be the empty string.
`MULTIBUILDTOP'
`config-ml.in' will set this to a sequence of `../' strings, where
the number of strings is number of multilib levels in the object
directory. The default value should be the empty string. This
will differ from `MULTISRCTOP' when configuring in the source tree
(which is not recommended).
`MULTIDIRS'
In the top level `Makefile' only, `config-ml.in' will set this to
the list of multilib subdirectories. The default value should be
the empty string.
`MULTISUBDIR'
`config-ml.in' will set this to the installed subdirectory name to
use for this subdirectory, with a leading `/'. The default value
shold be the empty string.
`MULTIDO'
`MULTICLEAN'
In the top level `Makefile' only, `config-ml.in' will set these
variables to commands to use when doing a recursive make. These
variables should both default to the string `true', so that by
default nothing happens.
All references to the parent of the source directory should use the
variable `MULTISRCTOP'. Instead of writing `$(srcdir)/..', you must
write `$(srcdir)/$(MULTISRCTOP)..'.
Similarly, references to the parent of the object directory should
use the variable `MULTIBUILDTOP'.
In the installation target, the libraries should be installed in the
subdirectory `MULTISUBDIR'. Instead of installing
`$(libdir)/libfoo.a', install `$(libdir)$(MULTISUBDIR)/libfoo.a'.
The `config-ml.in' script also modifies the top level `Makefile' to
add `multi-do' and `multi-clean' targets which are used when building
multilibs.
The default target of the `Makefile' should include the following
command:
@$(MULTIDO) $(FLAGS_TO_PASS) DO=all multi-do
This assumes that `$(FLAGS_TO_PASS)' is defined as a set of variables
to pass to a recursive invocation of `make'. This will build all the
multilibs. Note that the default value of `MULTIDO' is `true', so by
default this command will do nothing. It will only do something in the
top level `Makefile' if multilibs were enabled.
The `install' target of the `Makefile' should include the following
command:
@$(MULTIDO) $(FLAGS_TO_PASS) DO=install multi-do
In general, any operation, other than clean, which should be
performed on all the multilibs should use a `$(MULTIDO)' line, setting
the variable `DO' to the target of each recursive call to `make'.
The `clean' targets (`clean', `mostlyclean', etc.) should use
`$(MULTICLEAN)'. For example, the `clean' target should do this:
@$(MULTICLEAN) DO=clean multi-clean
File: configure.info, Node: FAQ, Next: Index, Prev: Multilibs, Up: Top
Frequently Asked Questions
**************************
Which do I run first, `autoconf' or `automake'?
Except when you first add autoconf or automake support to a
package, you shouldn't run either by hand. Instead, configure
with the `--enable-maintainer-mode' option, and let `make' take
care of it.
`autoconf' says something about undefined macros.
This means that you have macros in your `configure.in' which are
not defined by `autoconf'. You may be using an old version of
`autoconf'; try building and installing a newer one. Make sure the
newly installled `autoconf' is first on your `PATH'. Also, see
the next question.
My `configure' script has stuff like `CY_GNU_GETTEXT' in it.
This means that you have macros in your `configure.in' which should
be defined in your `aclocal.m4' file, but aren't. This usually
means that `aclocal' was not able to appropriate definitions of the
macros. Make sure that you have installed all the packages you
need. In particular, make sure that you have installed libtool
(this is where `AM_PROG_LIBTOOL' is defined) and gettext (this is
where `CY_GNU_GETTEXT' is defined, at least in the Cygnus version
of gettext).
My `Makefile' has `@' characters in it.
This may mean that you tried to use an autoconf substitution in
your `Makefile.in' without adding the appropriate `AC_SUBST' call
to your `configure' script. Or it may just mean that you need to
rebuild `Makefile' in your build directory. To rebuild `Makefile'
from `Makefile.in', run the shell script `config.status' with no
arguments. If you need to force `configure' to run again, first
run `config.status --recheck'. These runs are normally done
automatically by `Makefile' targets, but if your `Makefile' has
gotten messed up you'll need to help them along.
Why do I have to run both `config.status --recheck' and `config.status'?
Normally, you don't; they will be run automatically by `Makefile'
targets. If you do need to run them, use `config.status --recheck'
to run the `configure' script again with the same arguments as the
first time you ran it. Use `config.status' (with no arguments) to
regenerate all files (`Makefile', `config.h', etc.) based on the
results of the configure script. The two cases are separate
because it isn't always necessary to regenerate all the files
after running `config.status --recheck'. The `Makefile' targets
generated by automake will use the environment variables
`CONFIG_FILES' and `CONFIG_HEADERS' to only regenerate files as
they are needed.
What is the Cygnus tree?
The Cygnus tree is used for various packages including gdb, the GNU
binutils, and egcs. It is also, of course, used for Cygnus
releases. It is the build system which was developed at Cygnus,
using the Cygnus configure script. It permits building many
different packages with a single configure and make. The
configure scripts in the tree are being converted to autoconf, but
the general build structure remains intact.
Why do I have to keep rebuilding and reinstalling the tools?
I know, it's a pain. Unfortunately, there are bugs in the tools
themselves which need to be fixed, and each time that happens
everybody who uses the tools need to reinstall new versions of
them. I don't know if there is going to be a clever fix until the
tools stabilize.
Why not just have a Cygnus tree `make' target to update the tools?
The tools unfortunately need to be installed before they can be
used. That means that they must be built using an appropriate
prefix, and it seems unwise to assume that every configuration
uses an appropriate prefix. It might be possible to make them
work in place, or it might be possible to install them in some
subdirectory; so far these approaches have not been implemented.
File: configure.info, Node: Index, Prev: FAQ, Up: Top
Index
*****
* Menu:
* --build option: Build and Host Options.
* --host option: Build and Host Options.
* --target option: Specifying the Target.
* _GNU_SOURCE: Write configure.in.
* AC_CANONICAL_HOST: Using the Host Type.
* AC_CANONICAL_SYSTEM: Using the Target Type.
* AC_CONFIG_HEADER: Write configure.in.
* AC_EXEEXT: Write configure.in.
* AC_INIT: Write configure.in.
* AC_OUTPUT: Write configure.in.
* AC_PREREQ: Write configure.in.
* AC_PROG_CC: Write configure.in.
* AC_PROG_CXX: Write configure.in.
* acconfig.h: Written Developer Files.
* acconfig.h, writing: Write acconfig.h.
* acinclude.m4: Written Developer Files.
* aclocal.m4: Generated Developer Files.
* AM_CONFIG_HEADER: Write configure.in.
* AM_DISABLE_SHARED: Write configure.in.
* AM_EXEEXT: Write configure.in.
* AM_INIT_AUTOMAKE: Write configure.in.
* AM_MAINTAINER_MODE: Write configure.in.
* AM_PROG_LIBTOOL: Write configure.in.
* AM_PROG_LIBTOOL in configure: FAQ.
* build option: Build and Host Options.
* building with a cross compiler: Canadian Cross.
* canadian cross: Canadian Cross.
* canadian cross in configure: CCross in Configure.
* canadian cross in cygnus tree: CCross in Cygnus Tree.
* canadian cross in makefile: CCross in Make.
* canadian cross, configuring: Build and Host Options.
* canonical system names: Configuration Names.
* config.cache: Build Files Description.
* config.h: Build Files Description.
* config.h.in: Generated Developer Files.
* config.in: Generated Developer Files.
* config.status: Build Files Description.
* config.status --recheck: FAQ.
* configuration names: Configuration Names.
* configuration triplets: Configuration Names.
* configure: Generated Developer Files.
* configure build system: Build and Host Options.
* configure host: Build and Host Options.
* configure target: Specifying the Target.
* configure.in: Written Developer Files.
* configure.in, writing: Write configure.in.
* configuring a canadian cross: Build and Host Options.
* cross compiler: Cross Compilation Concepts.
* cross compiler, building with: Canadian Cross.
* cross tools: Cross Compilation Tools.
* CY_GNU_GETTEXT in configure: FAQ.
* cygnus configure: Cygnus Configure.
* goals: Goals.
* history: History.
* host names: Configuration Names.
* host option: Build and Host Options.
* host system: Host and Target.
* host triplets: Configuration Names.
* HOST_CC: CCross in Make.
* libg++ configure: Cygnus Configure in C++ Libraries.
* libio configure: Cygnus Configure in C++ Libraries.
* libstdc++ configure: Cygnus Configure in C++ Libraries.
* Makefile: Build Files Description.
* Makefile, garbage characters: FAQ.
* Makefile.am: Written Developer Files.
* Makefile.am, writing: Write Makefile.am.
* Makefile.in: Generated Developer Files.
* multilibs: Multilibs.
* stamp-h: Build Files Description.
* stamp-h.in: Generated Developer Files.
* system names: Configuration Names.
* system types: Configuration Names.
* target option: Specifying the Target.
* target system: Host and Target.
* triplets: Configuration Names.
* undefined macros: FAQ.
Go to most recent revision | Compare with Previous | Blame | View Log