OpenCores
URL https://opencores.org/ocsvn/or1k/or1k/trunk

Subversion Repositories or1k

[/] [or1k/] [trunk/] [insight/] [etc/] [configure.info-3] - Rev 1765

Compare with Previous | Blame | View Log

This is configure.info, produced by makeinfo version 4.0 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.


Compare with Previous | Blame | View Log

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.