-Copyright 1994, 1995, 1996, 1999, 2000, 2001, 2002 Free Software
-Foundation, Inc.
+Installation Instructions
+*************************
- This file is free documentation; the Free Software Foundation gives
+Copyright (C) 1994, 1995, 1996, 1999, 2000, 2001, 2002, 2004, 2005,
+2006, 2007 Free Software Foundation, Inc.
+
+This file is free documentation; the Free Software Foundation gives
unlimited permission to copy, distribute and modify it.
+Glog-Specific Install Notes
+================================
+
+*** NOTE FOR 64-BIT LINUX SYSTEMS
+
+The glibc built-in stack-unwinder on 64-bit systems has some problems
+with the glog libraries. (In particular, if you are using
+InstallFailureSignalHandler(), the signal may be raised in the middle
+of malloc, holding some malloc-related locks when they invoke the
+stack unwinder. The built-in stack unwinder may call malloc
+recursively, which may require the thread to acquire a lock it already
+holds: deadlock.)
+
+For that reason, if you use a 64-bit system and you need
+InstallFailureSignalHandler(), we strongly recommend you install
+libunwind before trying to configure or install google glog.
+libunwind can be found at
+
+ http://download.savannah.nongnu.org/releases/libunwind/libunwind-snap-070410.tar.gz
+
+Even if you already have libunwind installed, you will probably still
+need to install from the snapshot to get the latest version.
+
+CAUTION: if you install libunwind from the URL above, be aware that
+you may have trouble if you try to statically link your binary with
+glog: that is, if you link with 'gcc -static -lgcc_eh ...'. This
+is because both libunwind and libgcc implement the same C++ exception
+handling APIs, but they implement them differently on some platforms.
+This is not likely to be a problem on ia64, but may be on x86-64.
+
+Also, if you link binaries statically, make sure that you add
+-Wl,--eh-frame-hdr to your linker options. This is required so that
+libunwind can find the information generated by the compiler required
+for stack unwinding.
+
+Using -static is rare, though, so unless you know this will affect you
+it probably won't.
+
+If you cannot or do not wish to install libunwind, you can still try
+to use two kinds of stack-unwinder: 1. glibc built-in stack-unwinder
+and 2. frame pointer based stack-unwinder.
+
+1. As we already mentioned, glibc's unwinder has a deadlock issue.
+However, if you don't use InstallFailureSignalHandler() or you don't
+worry about the rare possibilities of deadlocks, you can use this
+stack-unwinder. If you specify no options and libunwind isn't
+detected on your system, the configure script chooses this unwinder by
+default.
+
+2. The frame pointer based stack unwinder requires that your
+application, the glog library, and system libraries like libc, all be
+compiled with a frame pointer. This is *not* the default for x86-64.
+
+If you are on x86-64 system, know that you have a set of system
+libraries with frame-pointers enabled, and compile all your
+applications with -fno-omit-frame-pointer, then you can enable the
+frame pointer based stack unwinder by passing the
+--enable-frame-pointers flag to configure.
+
Basic Installation
==================
- These are generic installation instructions.
+Briefly, the shell commands `./configure; make; make install' should
+configure, build, and install this package. The following
+more-detailed instructions are generic; see the `README' file for
+instructions specific to this package.
The `configure' shell script attempts to guess correct values for
various system-dependent variables used during compilation. It uses
It can also use an optional file (typically called `config.cache'
and enabled with `--cache-file=config.cache' or simply `-C') that saves
-the results of its tests to speed up reconfiguring. (Caching is
+the results of its tests to speed up reconfiguring. Caching is
disabled by default to prevent problems with accidental use of stale
-cache files.)
+cache files.
If you need to do unusual things to compile the package, please try
to figure out how `configure' could check whether to do them, and mail
may remove or edit it.
The file `configure.ac' (or `configure.in') is used to create
-`configure' by a program called `autoconf'. You only need
-`configure.ac' if you want to change it or regenerate `configure' using
-a newer version of `autoconf'.
+`configure' by a program called `autoconf'. You need `configure.ac' if
+you want to change it or regenerate `configure' using a newer version
+of `autoconf'.
The simplest way to compile this package is:
1. `cd' to the directory containing the package's source code and type
- `./configure' to configure the package for your system. If you're
- using `csh' on an old version of System V, you might need to type
- `sh ./configure' instead to prevent `csh' from trying to execute
- `configure' itself.
+ `./configure' to configure the package for your system.
- Running `configure' takes awhile. While running, it prints some
- messages telling which features it is checking for.
+ Running `configure' might take a while. While running, it prints
+ some messages telling which features it is checking for.
2. Type `make' to compile the package.
all sorts of other programs in order to regenerate files that came
with the distribution.
+ 6. Often, you can also type `make uninstall' to remove the installed
+ files again.
+
Compilers and Options
=====================
- Some systems require unusual options for compilation or linking that
-the `configure' script does not know about. Run `./configure --help'
-for details on some of the pertinent environment variables.
+Some systems require unusual options for compilation or linking that the
+`configure' script does not know about. Run `./configure --help' for
+details on some of the pertinent environment variables.
You can give `configure' initial values for configuration parameters
by setting variables in the command line or in the environment. Here
is an example:
- ./configure CC=c89 CFLAGS=-O2 LIBS=-lposix
+ ./configure CC=c99 CFLAGS=-g LIBS=-lposix
*Note Defining Variables::, for more details.
Compiling For Multiple Architectures
====================================
- You can compile the package for more than one kind of computer at the
+You can compile the package for more than one kind of computer at the
same time, by placing the object files for each architecture in their
-own directory. To do this, you must use a version of `make' that
-supports the `VPATH' variable, such as GNU `make'. `cd' to the
+own directory. To do this, you can use GNU `make'. `cd' to the
directory where you want the object files and executables to go and run
the `configure' script. `configure' automatically checks for the
source code in the directory that `configure' is in and in `..'.
- If you have to use a `make' that does not support the `VPATH'
-variable, you have to compile the package for one architecture at a
-time in the source code directory. After you have installed the
-package for one architecture, use `make distclean' before reconfiguring
-for another architecture.
+ With a non-GNU `make', it is safer to compile the package for one
+architecture at a time in the source code directory. After you have
+installed the package for one architecture, use `make distclean' before
+reconfiguring for another architecture.
Installation Names
==================
- By default, `make install' will install the package's files in
-`/usr/local/bin', `/usr/local/man', etc. You can specify an
-installation prefix other than `/usr/local' by giving `configure' the
-option `--prefix=PATH'.
+By default, `make install' installs the package's commands under
+`/usr/local/bin', include files under `/usr/local/include', etc. You
+can specify an installation prefix other than `/usr/local' by giving
+`configure' the option `--prefix=PREFIX'.
You can specify separate installation prefixes for
architecture-specific files and architecture-independent files. If you
-give `configure' the option `--exec-prefix=PATH', the package will use
-PATH as the prefix for installing programs and libraries.
-Documentation and other data files will still use the regular prefix.
+pass the option `--exec-prefix=PREFIX' to `configure', the package uses
+PREFIX as the prefix for installing programs and libraries.
+Documentation and other data files still use the regular prefix.
In addition, if you use an unusual directory layout you can give
-options like `--bindir=PATH' to specify different values for particular
+options like `--bindir=DIR' to specify different values for particular
kinds of files. Run `configure --help' for a list of the directories
you can set and what kinds of files go in them.
Optional Features
=================
- Some packages pay attention to `--enable-FEATURE' options to
+Some packages pay attention to `--enable-FEATURE' options to
`configure', where FEATURE indicates an optional part of the package.
They may also pay attention to `--with-PACKAGE' options, where PACKAGE
is something like `gnu-as' or `x' (for the X Window System). The
Specifying the System Type
==========================
- There may be some features `configure' cannot figure out
-automatically, but needs to determine by the type of machine the package
-will run on. Usually, assuming the package is built to be run on the
-_same_ architectures, `configure' can figure that out, but if it prints
-a message saying it cannot guess the machine type, give it the
+There may be some features `configure' cannot figure out automatically,
+but needs to determine by the type of machine the package will run on.
+Usually, assuming the package is built to be run on the _same_
+architectures, `configure' can figure that out, but if it prints a
+message saying it cannot guess the machine type, give it the
`--build=TYPE' option. TYPE can either be a short name for the system
type, such as `sun4', or a canonical name which has the form:
need to know the machine type.
If you are _building_ compiler tools for cross-compiling, you should
-use the `--target=TYPE' option to select the type of system they will
+use the option `--target=TYPE' to select the type of system they will
produce code for.
If you want to _use_ a cross compiler, that generates code for a
Sharing Defaults
================
- If you want to set default values for `configure' scripts to share,
-you can create a site shell script called `config.site' that gives
-default values for variables like `CC', `cache_file', and `prefix'.
+If you want to set default values for `configure' scripts to share, you
+can create a site shell script called `config.site' that gives default
+values for variables like `CC', `cache_file', and `prefix'.
`configure' looks for `PREFIX/share/config.site' if it exists, then
`PREFIX/etc/config.site' if it exists. Or, you can set the
`CONFIG_SITE' environment variable to the location of the site script.
Defining Variables
==================
- Variables not defined in a site shell script can be set in the
+Variables not defined in a site shell script can be set in the
environment passed to `configure'. However, some packages may run
configure again during the build, and the customized values of these
variables may be lost. In order to avoid this problem, you should set
./configure CC=/usr/local2/bin/gcc
-will cause the specified gcc to be used as the C compiler (unless it is
+causes the specified `gcc' to be used as the C compiler (unless it is
overridden in the site shell script).
+Unfortunately, this technique does not work for `CONFIG_SHELL' due to
+an Autoconf bug. Until the bug is fixed you can use this workaround:
+
+ CONFIG_SHELL=/bin/bash /bin/bash ./configure CONFIG_SHELL=/bin/bash
+
`configure' Invocation
======================
- `configure' recognizes the following options to control how it
-operates.
+`configure' recognizes the following options to control how it operates.
`--help'
`-h'
projects / platform / upstream / glog.git / blobdiff