We use srcdir to refer to the toplevel source directory for GCC; we use objdir to refer to the toplevel build/object directory.
If you obtained the sources via CVS, srcdir must refer to the top gcc directory, the one where the MAINTAINERS can be found, and not its gcc subdirectory, otherwise the build will fail.
If either srcdir or objdir is located on an automounted NFS file system, the shell's built-in pwd command will return temporary pathnames. Using these can lead to various sorts of build problems. To avoid this issue, set the PWDCMD environment variable to an automounter-aware pwd command, e.g., pawd or amq -w, during the configuration and build phases.
First, we highly recommend that GCC be built into a separate directory than the sources which does not reside within the source tree. This is how we generally build GCC; building where srcdir == objdir should still work, but doesn't get extensive testing; building where objdir is a subdirectory of srcdir is unsupported.
If you have previously built GCC in the same directory for a different target machine, do make distclean to delete all files that might be invalid. One of the files this deletes is Makefile; if make distclean complains that Makefile does not exist or issues a message like “don't know how to make distclean” it probably means that the directory is already suitably clean. However, with the recommended method of building in a separate objdir, you should simply use a different objdir for each target.
Second, when configuring a native system, either cc or gcc must be in your path or you must set CC in your environment before running configure. Otherwise the configuration scripts may fail.
Note that the bootstrap compiler and the resulting GCC must be link compatible, else the bootstrap will fail with linker errors about incompatible object file formats. Several multilibed targets are affected by this requirement, see host/target specific installation notes.
To configure GCC:
% mkdir objdir
% cd objdir
% srcdir/configure [options] [target]
Use options to override several configure time options for GCC. A list of supported options follows; configure --help may list other options, but those not listed below may not work and should not normally be used.
Note that each --enable option has a corresponding --disable option and that each --with option has a corresponding --without option.
--prefix=dirnameWe highly recommend against dirname being the same or a subdirectory of objdir or vice versa. If specifying a directory beneath a user's home directory tree, some shells will not expand dirname correctly if it contains the ~ metacharacter; use $HOME instead.
The following standard autoconf options are supported. Normally you should not need to use these options.
--exec-prefix=dirname--bindir=dirname--libdir=dirname--libexecdir=dirname--with-slibdir=dirname--infodir=dirname--datadir=dirname--mandir=dirname--with-gxx-include-dir=dirname--program-prefix=prefix--program-suffix=suffix--program-transform-name=patternAll three options can be combined and used together, resulting in more complex conversion patterns. As a basic rule, prefix (and suffix) are prepended (appended) before further transformations can happen with a special transformation script pattern.
As currently implemented, this option only takes effect for native builds; cross compiler binaries' names are not transformed even when a transformation is explicitly asked for by one of these options.
For native builds, some of the installed programs are also installed with the target alias in front of their name, as in i686-pc-linux-gnu-gcc. All of the above transformations happen before the target alias is prepended to the name—so, specifying --program-prefix=foo- and program-suffix=-3.1, the resulting binary would be installed as /usr/local/bin/i686-pc-linux-gnu-foo-gcc-3.1.
As a last shortcoming, none of the installed Ada programs are
transformed yet, which will be fixed in some time.
--with-local-prefix=dirnameYou should specify --with-local-prefix only if your site has a different convention (not /usr/local) for where to put site-specific files.
The default value for --with-local-prefix is /usr/local regardless of the value of --prefix. Specifying --prefix has no effect on which directory GCC searches for local header files. This may seem counterintuitive, but actually it is logical.
The purpose of --prefix is to specify where to install GCC. The local header files in /usr/local/include—if you put any in that directory—are not part of GCC. They are part of other programs—perhaps many others. (GCC installs its own header files in another directory which is based on the --prefix value.)
Both the local-prefix include directory and the GCC-prefix include directory are part of GCC's “system include” directories. Although these two directories are not fixed, they need to be searched in the proper order for the correct processing of the include_next directive. The local-prefix include directory is searched before the GCC-prefix include directory. Another characteristic of system include directories is that pedantic warnings are turned off for headers in these directories.
Some autoconf macros add -I directory options to the compiler command line, to ensure that directories containing installed packages' headers are searched. When directory is one of GCC's system include directories, GCC will ignore the option so that system directories continue to be processed in the correct order. This may result in a search order different from what was specified but the directory will still be searched.
GCC automatically searches for ordinary libraries using GCC_EXEC_PREFIX. Thus, when the same installation prefix is used for both GCC and packages, GCC will automatically search for both headers and libraries. This provides a configuration that is easy to use. GCC behaves in a manner similar to that when it is installed as a system compiler in /usr.
Sites that need to install multiple versions of GCC may not want to use the above simple configuration. It is possible to use the --program-prefix, --program-suffix and --program-transform-name options to install multiple versions into a single directory, but it may be simpler to use different prefixes and the --with-local-prefix option to specify the location of the site-specific files for each version. It will then be necessary for users to specify explicitly the location of local site libraries (e.g., with LIBRARY_PATH).
The same value can be used for both --with-local-prefix and --prefix provided it is not /usr. This can be used to avoid the default search of /usr/local/include.
Do not specify /usr as the --with-local-prefix! The directory you use for --with-local-prefix must not contain any of the system's standard header files. If it did contain them, certain programs would be miscompiled (including GNU Emacs, on certain targets), because this would override and nullify the header file corrections made by the fixincludes script.
Indications are that people who use this option use it based on mistaken
ideas of what it is for. People use it as if it specified where to
install part of GCC. Perhaps they make this assumption because
installing GCC creates the directory.
--enable-shared[=package[,...]]If a list of packages is given as an argument, build shared libraries only for the listed packages. For other packages, only static libraries will be built. Package names currently recognized in the GCC tree are libgcc (also known as gcc), libstdc++ (not libstdc++-v3), libffi, zlib, boehm-gc, ada, libada, libjava and libobjc. Note libiberty does not support shared libraries at all.
Use --disable-shared to build only static libraries. Note that
--disable-shared does not accept a list of package names as
argument, only --enable-shared does.
--with-gnu-asThe following systems are the only ones where it makes a difference whether you use the GNU assembler. On any other system, --with-gnu-as has no effect.
On the systems listed above (except for the HP-PA, the SPARC, for ISC on
the 386, if you use the GNU assembler, you should also use the GNU linker
(and specify --with-gnu-ld).
--with-as=pathname--with-gnu-ld--with-ld=pathname--with-stabsOn MIPS based systems and on Alphas, you must specify whether you want GCC to create the normal ECOFF debugging format, or to use BSD-style stabs passed through the ECOFF symbol table. The normal ECOFF debug format cannot fully handle languages other than C. BSD stabs format can handle other languages, but it only works with the GNU debugger GDB.
Normally, GCC uses the ECOFF debugging format by default; if you prefer BSD stabs, specify --with-stabs when you configure GCC.
No matter which default you choose when you configure GCC, the user can use the -gcoff and -gstabs+ options to specify explicitly the debug format for a particular compilation.
--with-stabs is meaningful on the ISC system on the 386, also, if --with-gas is used. It selects use of stabs debugging information embedded in COFF output. This kind of debugging information supports C++ well; ordinary COFF debugging information does not.
--with-stabs is also meaningful on 386 systems running SVR4. It
selects use of stabs debugging information embedded in ELF output. The
C++ compiler currently (2.6.0) does not support the DWARF debugging
information normally used on 386 SVR4 platforms; stabs provide a
workable alternative. This requires gas and gdb, as the normal SVR4
tools can not generate or interpret stabs.
--disable-multilibSome targets provide finer-grained control over which multilibs are built (e.g., --disable-softfloat):
arc-*-elf*arm-*-*m68*-*-*mips*-*-*powerpc*-*-*, rs6000*-*-*--enable-threadsIn general, the best (and, in many cases, the only known) threading
model available will be configured for use. Beware that on some
systems, GCC has not been taught what threading models are generally
available for the system. In this case, --enable-threads is an
alias for --enable-threads=single.
--disable-threads--enable-threads=libaixdcegnatmachnoposixposix95rtemssinglesolarisvxworkswin32nks--with-cpu=cpu--with-schedule=cpu--with-arch=cpu--with-tune=cpu--with-abi=abi--with-fpu=type--with-float=type--with-divide=typetrapsbreaks--enable-altivec--enable-__cxa_atexit--enable-target-optspace--disable-cpp--with-cpp-install-dir=dirname--enable-initfini-array.init_array and .fini_array
(instead of .init and .fini) for constructors and
destructors. Option --disable-initfini-array has the
opposite effect. If neither option is specified, the configure script
will try to guess whether the .init_array and
.fini_array sections are supported and, if they are, use them.
--enable-maintainer-modegettext tools
to do so.
--enable-generated-files-in-srcdirIf you configure with --enable-generated-files-in-srcdir then those
generated files will go into the source directory. This is mainly intended
for generating release or prerelease tarballs of the GCC sources, since it
is not a requirement that the users of source releases to have flex, bison, or
makeinfo.
--enable-version-specific-runtime-libs--enable-languages=lang1,lang2,... grep language= */config-lang.in
Currently, you can use any of the following:
ada, c, c++, f77, f95, java,
objc, obj-c++.
Building the Ada compiler has special requirements, see below.
If you do not pass this flag, all languages available in the gcc
sub-tree will be configured. Re-defining LANGUAGES when calling
make bootstrap does not work anymore, as those
language sub-directories might not have been configured!
--disable-libada--with-dwarf2--enable-win32-registry--enable-win32-registry=key--disable-win32-registry HKEY_LOCAL_MACHINE\SOFTWARE\Free Software Foundation\key
key defaults to GCC version number, and can be overridden by the
--enable-win32-registry=key option. Vendors and distributors
who use custom installers are encouraged to provide a different key,
perhaps one comprised of vendor name and GCC version number, to
avoid conflict with existing installations. This feature is enabled
by default, and can be disabled by --disable-win32-registry
option. This option has no effect on the other hosts.
--nfp--enable-werror--disable-werror--enable-werror=yes--enable-werror=no--enable-checking--enable-checking=list--enable-coverage--enable-coverage=level--enable-gather-detailed-mem-stats--enable-nls--disable-nls--with-included-gettext--with-catgetsgettext but has the
inferior catgets interface, the GCC build procedure normally
ignores catgets and instead uses GCC's copy of the GNU
gettext library. The --with-catgets option causes the
build procedure to use the host's catgets in this situation.
--with-libiconv-prefix=dir--enable-obsoleteAll support for systems which have been obsoleted in one release of GCC is removed entirely in the next major release, unless someone steps forward to maintain the port.
The following options only apply to building cross compilers.
--with-sysroot--with-sysroot=dir--with-headers--with-headers=dir--without-headers--with-libs--with-libs=``dir1 dir2 ... dirN''--with-newlib__eprintf to be
omitted from libgcc.a on the assumption that it will be provided by
newlib.
The following options apply to the build of the Fortran front end.
--with-gmp=pathname--with-mpfr=pathname--with-gmp-dir=pathname--with-mpfr-dir=pathnameThe following option applies to the build of the Java front end.
--disable-libgcjThe following options apply to building libgcj.
--disable-getenv-properties--enable-hash-synchronization--enable-interpreter--disable-java-net--disable-jvmpi--with-ecos--without-libffi--enable-libgcj-debug--enable-libgcj-multifile--with-libiconv-prefix=DIR--enable-sjlj-exceptionsbuiltin_setjmp for exceptions. configure
ordinarily picks the correct value based on the platform. Only use
this option if you are sure you need a different setting.
--with-system-zlib--with-win32-nlsapi=ansi, unicows or unicodeansichar and the Win32 A functions natively,
translating to and from UNICODE when using these functions. If
unspecified, this is the default.
unicowsWCHAR and Win32 W functions natively. Adds
-lunicows to libgcj.spec to link with libunicows.
unicows.dll needs to be deployed on Microsoft Windows 9X machines
running built executables. libunicows.a, an open-source
import library around Microsoft's unicows.dll, is obtained from
http://libunicows.sourceforge.net/, which also gives details
on getting unicows.dll from Microsoft.
unicodeWCHAR and Win32 W functions natively. Does not
add -lunicows to libgcj.spec. The built executables will
only run on Microsoft Windows NT and above.
--with-x--enable-java-awt=PEER(S)--enable-gtk-cairo--enable-java-gc=TYPE--disable-gtktest--disable-glibtest--with-libart-prefix=PFX--with-libart-exec-prefix=PFX--disable-libarttestReturn to the GCC Installation page
Please send FSF & GNU inquiries & questions to gnu@gnu.org. There are also other ways to contact the FSF.
These pages are maintained by the GCC team.
For questions related to the use of GCC, please consult these web pages and the GCC manuals. If that fails, the gcc-help@gcc.gnu.org mailing list might help.Copyright (C) Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA.
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
| Last modified 2004-11-23 |
|